Variorum

Next...

Glad they're working for you! I see you named your song after one of Elon Musk's kids... 😉

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! 😁