Variorum

Way to go knowing about a plugin that would be almost impossible to find for a mere mortal! 😁 Looks like there's a slightly newer version available dxshell_v1.0.5b.zip (8 years newer!) but according to the change log it only adds "midi program change message is not filtered anymore" I briefly considered writing a VST3 wrapper for the MFX since there are a lot of parallels between the two, but decided that it would be better to just rewrite the DX stuff as VST3 if the need arises. I'm still not a fan of Steinberg, partly because of statements like this "VST3 does not directly support MIDI. You can create note events and send them to an output queue." on the Steinberg forum (https://forums.steinberg.net/t/creating-a-midi-effect/201569). I don't understand Steinberg's seeming aversion to Midi handling in a VST. I'd rather have the MFX standard updated a bit and be available on a lot more DAWs. Alternatively, having the ability to drop a VST3 effect on a Midi track (if the effect was flagged something like "Fx|Midi") would be cool. I don't know which option is less impossible... getting most DAWs to support a common standard like MFX or getting Steinberg to fully (easily) support Midi in their interface.

Hey Dave... The note indicators are really just to give you some help if you're adjusting the response curve of your keyboard; they appear for external input data. The lines don't appear on playback because MFX plugins don't get the track data in real-time. It's supplied from the DAW in buffers before it's actually played, so if it was displayed, it would just be all the notes in that buffer appearing at once every quarter second or so (depending on the size of the buffer) before you actually heard them. I could technically create an internal clock and kinda fake a real-time display, but that would use up a lot of valuable CPU cycles. If you want to see how out of sync it is, try using controller data to modify parameters in MidiModulator. I do update that display so you can see that the parameters are changing, but it's definitely not in sync with the music. 😬

Sliding the clip under the loop caused it to break while I was debugging so I found what was causing it. I didn't try that in my first tests. Shouldn't happen, though (Doesn't happen in CbB or Sonar). I'll have a fix soon... Ok @Amberwolf, it should be fixed now. Grab it here.

Yeah, I missed this one. It's fixed now (in the 64Bit version also). Remember, you can just double-click the edit box and type in the CC, use the mouse wheel to scroll through the CCs, or right-click on the edit box and select Learn if you are assigning a knob or slider from you keyboard/controller. The only odd part is you have to actually type in a zero to switch the parameter back off (You can't do it using the mouse wheel). I don't remember why I did that, but I'm sure I had a good reason 🤔. The plugins lean a lot more toward mouse control than keyboard-only. This one's weird. I managed to get that to happen once after repeated loops, even moving the loop points around while playing, but couldn't get it to repeat while debugging. So... I added some checks in the code that processes the track data and added exception handlers that should prevent a crash in case the whatever is causing the problem happens again. The new version's here.

Hope that stays true I still don't know why there's an issue with your 8.5.3 and this isn't really a fix... more of a hack to get the plugins to work. But, it doesn't seem to cause any obvious issues so I modified all of them. DL them here. Let me know if you have any problems This one you can already do in CbB and Sonar by rendering the synth track (or just freezing it) and dragging the audio track to a midi track. It'll convert the audio to midi including adjusting the velocity of each note according the its volume. It works best if you turn off any synth effects (reverb, delay, etc.) first so the audio is clear. V-Vocal has an audio to midi function but I don't remember if it also adjusts the velocity of each note. I'll have to check later. I started an arpeggiator plugin a long time ago but never finished because there were so many really good VST arp plugins available. BlueARP is a good one.

WOOKIEE! IT'S TIME!

I don't hate you for that... I hate you because you shed all over the carpet!

No, display drivers wouldn't affect it. I've managed to duplicate the problem in my test harness by not initializing Gdiplus. Normally, the host program calls a pair of functions to start and stop Gdiplus. When I test the plugins, my test program calls these. If I comment out the gdiplus init, I get the same error I see in the dumps. I know SONAR 8.5.3 is calling these correctly because the plugins work here, but for some reason, there's a disconnect on your machine. I made another test plugin to check that theory (maybe). Same drill... unzip, register, and crank up SONAR. Grab it here.

Nah, I've been going over the (non-debug) crash dumps and I know exactly where and why the crashes occur in the code... Gdiplus calls are failing. Now I'm trying to figure why the calls work on my machines but fail on yours. I'm hoping it's just a version mismatch of some kind. Need to do more research and experiments. When you get a chance, send me the version of your GdiPlus.dll: This is mine... GdiPlus.dll (32 Bit) Location: C:\Windows\SysWOW64 Version: 10.0.19041.4597 EDIT: I'm figuring some of this dump file stuff out (slowly)... It appears from the dump files and the loaded GdiPlus.dll that your Windows version is 10.0.10586, that would be from 2015. I'm leaning toward some compatibility issues, but I'm not positive yet. EDIT AGAIN: You can't install the10586 libs anymore but luckily I still have them on my machine (one of the advantages of using the same box for years 😋) so I built a version of CSHumanize using them. I really don't know if it'll make a difference, but give it a try... Download it here.

You should only need to install Desktop development with C++, but beware it's a very large installation... 10's of GB. Didi installing the redistributables fix the crashing of the original (non-debug) plugins by any chance?

I'm kinda stumped so far. I extracted the DLLs you sent back and they Registered/Unregistered with no problems. The first thing you could try is installing the C++ x86 redistributables (https://aka.ms/vs/17/release/vc_redist.x86.exe) just to make sure you have the latest on your machine for projects built using VS2022. If it isn't that, I'll see if I can make up a dummy DLL that contains just the DllRegisterServer and DllUnregisterServer functions and make sure that works, then add the functions that actually write the new entries to the registry and see if that works, etc. until it breaks. It doesn't seem like it should be a problem with the redistributables because previous plugins were registering properly on your machine. I did have a problem a long time ago with permissions on registry keys (you can set the permissions and ownership on registry keys just like you can with files). The key's owner was listed as "Unknown Account" or something like that and I couldn't change owners, edit it, or even delete it. Had to use a Linux boot disk and a Windows Registry utility to fix it. BTW - I added you as a member on the Viramor Forum... UserName: AmberWolf, PW: <your dog's name, one word, all lowercase. We may have to move the convo there so as not to monopolize this forum. 😜 UPDATE - Nevermind about the redistributables, I'm pretty sure the problem is that the debug version needs the debug libraries to run. The C++ redistributable won't contain those, and having you install Visual Studio (mucho gigs) just to test the DLLs might be overkill 😬 It won't hurt to install the latest redistributables if you want to. At least it would rule out incompatibilities with the non-debug versions. You can just delete the debug versions...

Remember to extract the plugin DLLs from the zip before registering them. I've gotten distracted before, just double clicked on one of the zips and tried to register it... won't work! This is what I've used for a long time: ContextReg.zip Extract the contents and right click DLL_REG.reg and click Merge. It adds 2 entries to your explorer context menu (when you right-click on a file) to register and unregister a DLL. It also automatically elevates regsvr32 to run with administrator rights. Makes it really easy to quickly register/unregister the plugins as Administrator... I have to do it a lot DLL_REG_REMOVE.reg just removes those entries if you don't want to use it anymore. You'll probably have to close and re-open your explorer window to make the new context menu items show up after you merge the DLL_REG file. I double checked both of them here and they register fine. The only times I've had a problem registering is when I've tried it without admin rights or when I tried to register without actually extracting them (see above 🤪) Try the DLL_REG solution and let me know how it goes. If it still doesn't work we'll move to the CMD window (or Power Shell) started as admin and run regsvr32 from there.

At this point it's just a matter of professional pride! I'll get these things to work on a VIC-20 if I have to! 😁

Argh! The first thing I'll do is apply the 3 patches to get to 8.5.3 (I'm just running 8.5.0) to make sure we're using exactly the same executable. Second, I'll send you a debug version of CSHumanize and CSWaver since the errors in the dump files are slightly different between CSWaver and the others. The dumps will be much more useful when created from the debug versions. I may also send you a small dummy plugin that will contain certain graphics function types if I need to isolate those. The problem appears to be related to painting the graphics... for some of the plugins, anyway. One important question I forgot to ask... are you running Windows 10 32-Bit or 64-Bit? If you don't know/forgot, go to: Settings > System > About Near the top, under Device Specifications, check System Type. It'll say 64-bit operating system or 32-bit operating system. Pretty sure you're running 64 bit since you said you tried installing CbB which I believe has always been 64 Bit only. I've updated to 8.5.3 and everything still works so, Plan B. Ok... edit number 47. Here are a couple of debug versions. I don't need to tell you the procedure since you already seem to be a pro 🙂 Send me the inevitable crash dumps for these two: Debug.zip

Cool! I slapped it on the project page. I don't have that many keyboards, but I'm pretty close on the monitors 😁

Ok, I got these plugins for you to try out... They all seem to work fine now in 32Bit Sonar8.5. Not difficult to get them to work, just tedious... I put them all in one zipped up file here. Extract the folder anywhere on your computer and use the Install_ALL.bat to register all of them, or if you're chicken, you can just register and test them individually 🤪 It's not absolutely necessary, but it might be a good idea to make sure any previous Viramor plugins are unregistered before trying the new ones. These will be the only ones I do for a while... they're the recently re-written group that use a common codebase so they were relatively easy to modify. The others are still a mish-mash of code. When I finally rewrite those, I'll make sure I have 32Bit versions available. Good Luck! Keep a fire extinguisher handy!

Important bit of advice for Arduino coding... use Visual Studio Code (https://code.visualstudio.com/) instead of the Arduino IDE. It's much better and easier to use (and free!). If you search on Google, you'll find some good tutorials on how to configure everything for Arduino. Good luck with the cloning software. There used to be a few good free applications to do it, but they've pretty much disappeared. BTW - Dev environment is still installing on the laptop...

Trumpets (and brass) are mainly GPO5 with VSL Big Bang Orchestra and SINE Player - Rotary for support. The idea was to use all freely available VSTs in addition to GPO5. Pretty soon I'll spend a bit of money and remake it using 8Dio instruments. They've been having some ridiculous sales lately and I'm hoping for a big one this Black Friday 😁 Of course that means I'll have to buy another SSD to hold them 🙄

I'd like to find out what part of the code is failing in 32Bit. I have some suspicions. Once I get everything installed on the laptop (very slow... it has a mechanical hard drive! May as well be a floppy disk) it shouldn't take long to sort out. Arduino is fun! Nothing like making little gadgets move with code 😋

I was afraid there might be a few issues just changing the configuration to 32Bit and recompiling. I resurrected an old I5 laptop and I'm installing the 32Bit version of SONAR 8.5 now. It'll take a while to install the updates and get a dev environment set up on it, but I should be able to test and debug the 32Bit version then... The crash dump will be helpful. At least I know the specific function that crashed... One of many, I suspect.

Well, I'm an idiot. I uploaded the regular 64Bit plugin instead of the new 32Bit. I've been trying to figure out why the plugin was registering incorrectly on your machine when it registers correctly on mine. I even looked at the file size of the uploaded DLL (which was 413KB) and thought it was right... the 32Bit plugin is 431KB... So yeah, I'm dyslexic? Anyway, thanks for the thorough registry analysis 😁 Try this one. It should hopefully might almost be the correct one (I'll re-download to make SURE): CSHumanize.dll Same as before; make sure the old plugin is unregistered, then register this one.

Nope... don't need it. Nah, I never actually built any of these as 32-Bit plugins... I don't have a 32-Bit SONAR installation to test them on. I do still have my nice boxed SONAR 8.5 installation discs, but I'm to afraid to install it (I understand how you feel about breaking something once you get everything working and stable 😬) But, I modified the CSHumanize project so it could be built as 32-Bit, wasn't terribly difficult. If you'd like, you can download it below and test it. You'll have to manually register it using regsvr32 (unregister the previous CSHumanize first, if you tried registering it). I have no way to test it here, but it compiles and registers fine 😜 If it does show up in SONAR, it'll confirm that you have the 32-Bit version installed... and it might even work! If it does, let me know what other plugins you want to use and I'll attempt to build 32-Bit versions of those, as well. If it doesn't work correctly, just unregister it and delete it... It won't mess up your current configuration.

Hey Amberwolf, My first guess of something that would cause the problem is if you're running a 32-bit version of Sonar 8.5.3. This would explain why the plugins register correctly but are not found by Sonar. A 32-bit application looks in a different place in the registry for its info. It looks like you're running the 64-bit version of Sonar because your install directory is C:\Program Files\Cakewalk\Shared MFX instead of C:\Program Files (x86)\Cakewalk\Shared MFX but since the directory can be changed when installing I need to make sure. TenCrazy makes 32-bit and 64-bit versions of the plugins, so my first question is... which version of those plugins did you successfully install. Both would install correctly on your 64-bit Windows machine, but (I'm pretty sure) only the 32-bit plugins would be recognized by Sonar if you have Sonar 32-bit installed. If you're definitely running the 64-bit version of Sonar, we'll have to try something else. I'll see if I can whip up a quick program to validate the registry entries. In the mean time, if you're running the 64-bit version of Sonar and you're familiar with regedit, you can check the following keys: Keys showing here should be picked up by Sonar 64-bit... Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Cakewalk Music Software\MIDI Filters Keys showing here should be picked up by Sonar 32-bit... Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cakewalk Music Software\MIDI Filters The keys shown won't make much sense to you, just let me know how many there are in each of these places. Ok... Run these two programs and copy and paste the results in a post here: MidiFXValidator(64Bit).exeMidiFXValidator(32Bit).exe Let me know if you have any problems running them. I'm just guessing at the latest .NET framework you have installed. I may have to try a different one.

Are you running the .bat file from the original directory? In other words, is CSMultiCompanderV2.dll in the same directory as the Install.bat file? If it is and you're still getting the error, open Power Shell (or a CMD window) as Administrator. If you right-click on the Windows Start icon you should see one of those in the list. CD to the directory containing Install.bat and CSMultiCompanderV2.dll and run this command: regsvr32 .\CSMultiCompanderV2.dll Let me know what happens...

Hmmm... That usually means regsvr32 isn't being run as administrator. The new Install.bat file automatically elevates permissions so you don't have to explicitly pick "Run as administrator", but it looks like something on your machine is preventing that?? Do you see this screen after running Install.bat? You can also right click on Install.bat and select "Run as administrator". That should allow it to register. If that still doesn't work, we can use Power Shell (or the command window) started as Admin to manually register it. Lemme know.