New MidiFX Available

[Amberwolf]

Here's a plugin request that woudl save me days or even weeks of work in a lot of projects.  (maybe something like this already exists, but I don't know about it)

   A "merge" plugin that the user can point to a midi file (or a clip on a track if that's easier) that then takes the notes played in a track that are used to play an arp in a synth (that this same MIDI file was the arp pattern for), and generates the MIDI output that the synth would have "seen" internally. 

Meaning, if a track just has long whole or quarter notes (etc) of whatever note values (single or chords, etc), then the plugin would play the arp pattern notes loaded into it in those values.  So I could put the plugin into the clip FX bin, apply MIDI FX on the clip (or track fx bin and apply to track, etc, though I don't usually do it that way because I want some notes unarped). 

This is because I want to use, for instance, the Z3TA arp to play it from in the initial inspiration and clip recording stage, but when editing I need access to the individual arped notes to change the note played, or their length, or even position, or even leave some out entirely.    Can't do that until I have the arp pattern as clips on the track...but to do that I have to stick the arp pattern on the track, then I have to manually change the pitch of each note in the pattern to match the notes I played, which is very tedious and has few shortcuts available, and takes a long time.  

 

Does this sound like anything you've already seen in a plugin, or something you'd be interested in making?  

If my description is insufficient I can try to come up with a better one. 

 

By it's I/O nature, it would also be an arp plugin, and so it could have the other types of controls such a plugin has, perhaps also including an editing screen for the pattern (but I'd be happy enough to do that part in a SONAR track like I already do, then export to a file I can then load in, as I already do). 

 

 

 

(Yes, SONAR 8.5.3 has a per-track arp I can load MIDI files into, but it doesn't (properly, or at all, don't recall which) obey the velocities on the arp patterns loaded, and only uses the static velocity set in it (dunno if that was intended or a bug, but it makes it unable to do what I need).  )

[Amberwolf]

  

On 9/6/2024 at 8:02 PM, Variorum said:

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.

 

Been poking at the test project tonite between involuntary naps, and CSHumanize hasn't crashed it yet; I have it in at least three MIDI tracks running live.

I also used it a number of project versions back to destructively live humanize the original synth clip by using LoopBe MIDI loopback to record the output of the track full of that clip to a second track feeding the synth.  (then I turned the synth's own up/down arp on to see how it might sound, and it was interesting so I left it in place, too).  Then I began editing out notes in various measures of the resulting recorded clip to make it more like a played part than a loop; it's somewhat interesting at this point and will probably become a "real" song. 

So whatever you did to this plugin, doing it to the others would probably make them work too. 👍

 

Didn't get the other laptop setup to test yet though.  

 

For the curious, this is what this plugin has helped me create so far

https://soundclick.com/share.cfm?id=14844484

Edited September 8 by Amberwolf

[Variorum]

14 hours ago, Amberwolf said:

CSHumanize hasn't crashed it yet

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

On 9/7/2024 at 1:07 AM, Amberwolf said:

A "merge" plugin that the user can point to a midi file

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.

[Amberwolf]

12 hours ago, Variorum said:

Hope that stays true  

So far, it has. I'll letcha know if that changes. 

 

 

12 hours ago, Variorum said:

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

I'll test the new ones shortly.  

EDIT: several hours later, I didn't get that done yet; I was still playing with that test project, which now has it's own thread since it's going to be a real project track for sure now. 

 

 

The first set of 32bit ones (that crash on the main machine) also crash the same way on the spare laptop with a clean setup of SONAR 32 bit, patched up to 8.5.3.  Presumably the same crashdump info, but I can post that if you can use it.  Hardware and OS version are the same as the main laptop. 

Neither has the bloatware usually preinstalled on these, thankfully they came fairly cleanly setup, and on the test laptop I just did the default install for SONAR and the patches (other than making sure it's still in the PF folder rather than PF x86, mostly to make it easier for me to find things as I'm used to looking there, and to ensure compatiblity with the few ancient things I have that don't know about the x86 version of the folder path and don't work with it (which might be why I used the regular PF in the first place--it's been so long I don't remember). 

 

The DS_Test version that works on the main one also works on the spare laptop.  I'll test the new ones on both, too. 

 

A thought:  Are there any services that gdiplus.dll depend on?  I have a bunch of services set to manual or outright disabled, to greatly speed up the computer and reduce glitches in recording and playback from them doing things I don't need to ever happen....

 

 

 

12 hours ago, Variorum said:

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.

It doesn't seem to work for me, but I don't recall that feature in the ancient SONAR I have. I only have the freeze option (there aren't any rendering ones, other than exporting a selection to an externally saved audio file). If I drag the audio to a midi track, it just sits there as an audio clip and the track doesn't do anything with it.  Would be a great function to have, though, so glad they added it somewhere along the line.  

I'll see if I can install CbB on the test laptop since it doesn't have anything to break yet, and then see if this can do what I'm after.  

 

But I suspect it won't without more extra work, because the synth sounds I am usually using don't always make exactly the same sound, volume, pitch, etc., (even with effects off) with different notes (number or length) being input, which is part of why I use them this way--they don't sound so mechanical.   (they do make the same output for the same input data, making them repeatable, just not with different input data).  So unless I use a patch that just makes like a sinewave at the same amplitude for whatever velocity input, regardless of any other note input or control info, any audio to midi conversion will give different velocity (and probably pitch) output than what I actually input, even without the internal arp running.  I'll have to test to see. 

 

FWIW, There is an option in the audiosnap toolbar to create a midi frle from the audio, but it won't convert the pitches, just the timing and velocity.    

 

I wish CAL still worked reliably; I could probably figure out how to make or adapt a CAL to do this, but I was never good at it anyway. 😊 

 

12 hours ago, Variorum said:

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.

While it's a thought, and is worth a try anyway:   For me, VVocal tends to crash projects, and doesn't seem to work on anything longer than a second or two (usually because of a crash, sometimes it just doesn't read the clips correctly or completely).   It may be able to do this kind of conversion, but it would have to be done (and then checked to make sure it's correct) in lots of very short segments, probably hundreds of them; I'm not sure it would save me much work.  

 

12 hours ago, Variorum said:

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.

Yeah, there are a lot of arp plugs, some of them with synths in them, etc., but...

The old SONAR I've got doesn't support VST MIDI *output* stuff AFAICT.  (it doesn't appear to even support feeding the onscreen controls from VST that have outputs for those back to the tracks to record automation from...if it's supposed to, then I must be doing it wrong--I wanted to use that function to save the live changes to Nerds.de's DelayLama VST some years back, and found I couldn't, though Nerds said DL supports doing it). 

If it does support it and I figure out how , then as long as the VST arp will output MIDI to a MIDI track that I can then record (or bounce, etc), to get me the final actual notes that a synth would play from "two arps in series" (functionally how what I am doing works), then that would accomplish my goal of getting a fully editable track full of notes.

I'll poke around at it and see what I'm missing to try to get the VST MIDI plug(s) to work, on the spare test laptop setup.  

Edited September 9 by Amberwolf

[Amberwolf]

Testing the new plugs, I found that if loop/autoshuttle is engaged in the transport, CSMidiModulator will cause SONAR to just POOF, no crashdump, as soon as the sometime before loop/autoshuttle hits the loop end point.  I suspect its at the point where the buffers for the plugin are hitting that point, something about how SONAR is feeding them during looping (I've had issues of various kinds with stuck notes or missed notes with various synths using looping, over the years, but not poofs) but I don't know how long it's buffers are. 

It happens so fast I can't be certain of the time, but I think it is at 3 measures into the 4 measure loop, which is 7:06 seconds out of 9:18 seconds.  My MIDI buffers are set to 250ms.  I haven't yet tested the results of changing buffer size, other than that it still happens whether I increase that 10x or decrease it to 1/10. 

Doesnt' matter if the MIDI is groove clips or just plain clips, or if it is one or multiple clips. 

It doesnt' happen if the MIDI does not extend beyond the loop end point.  Only poofs if there is MIDI beyond the loop end. 

Happens even if all of the MIDI is outside the loop; there just has to be some in the track within a measure of the loop end time (past it).   If it is further than that, it doesn't poof, and will sit there looping on nothing fine.  (further testing shows it stops happening if the midi is within about an eighth before the end of that measure, but sooner than that and poof). 

The further the MIDI is beyond the loop end, the closer the nowtime will reach to the loop end before poof.  

It happens even from a blank starting template, creating any MIDI note(s) and placing them within the above constraints, or using existing MIDI clips imported in, etc, as long as loop/autoshuttle is engaged, within above constraints. 

Doesnt' matter where the loop selection is in the timeline, as long as the MIDI is within the above constraints to the loop selection. 

 

It doesn't happen if it just hits the end of the MIDI in a track and the transport stops on it's own, with no loop/autshuttle engaged. 

It doesn't happen if there is no MIDI in the track (even if there's MIDI in other tracks). 

It doesnt' happen with any of the other plugins, just the modulator. 

 

If you need further info, let me know and I'll do the tests. 

 

 

 

Edited September 9 by Amberwolf

[Amberwolf]

Behavioral change request:

In MidiModulator UI, changing numbers in the CC boxes is more difficult than necessary. 

Except in one case, the user must first click in the box with the number to be changed, then select the text "OFF" with the mouse (can't be done with the keyboard and arrows, because the cursor is kept forced against the right edge of the box past "OFF"), then type the number you want. 

If you want a different number, you have to repeat this procedure, because as soon as you backspace or delete key the existing number out, you can't just type a new number as it now changes to "OFF". 

Additionally, if you have already selected "OFF" text, and accidentally type a non-numeric character, it unselects the text and you have to do it again. 

If you click in a box with a number, and don't backspace, you can type a number, but it is just inserted with the existing one, and the cursor is forced to the right side, past all of them, so you can't just hit "delete" (or arrow over to the one you want to go away and backspace), you have to backspace thru all of them and then your'e back to "OFF" and have to do the selection/etc. 

Better behavior would be to just replace the number or "OFF" in the box with whatever the user types once the box is clicked on to do this.

The one case that's different that is already the desired behavior is if you click on the first box, then tab to the next one with the keyboard, and it will preselect the "OFF" text and replace it with whatever number you type. 

 

 

Edited September 10 by Amberwolf

[Amberwolf]

Minor MidiModulator UI bug:  the numbers at the top of the Freq slider is only two digits wide, so anytime you go to a higher value it then show only the leftmost two digits, which is confusing.  

 

Since the result / output is still correct, this is just cosmetic and not very important. once the user realizes what is happening.

 The other sliders don't use more than two digits so they don't reveal this issue. 

[Variorum]

On 9/9/2024 at 10:54 PM, Amberwolf said:

the numbers at the top of the Freq slider is only two digits wide

Yeah, I missed this one. It's fixed now (in the 64Bit version also).

 

On 9/9/2024 at 10:48 PM, Amberwolf said:

In MidiModulator UI, changing numbers in the CC boxes is more difficult than necessary. 

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.

On 9/9/2024 at 5:30 PM, Amberwolf said:

I found that if loop/autoshuttle is engaged in the transport, CSMidiModulator will cause SONAR to just POOF

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.

[Amberwolf]

Thank you very much for the attempt...but the new version still POOFs reliably under the stated conditions on both my test system and my main one.   

Attached is an example project with the MIDI all within the loop, where it doesn't poof.  But drag the clip past the loop end even a note's worth, and POOF once it hits the spot close enough to the end of the loop.

I'm going to try to install CbB on the test laptop and see if it also happens there.

 

viramor test 9c.cwp

Edited Friday at 01:09 AM by Amberwolf

[Amberwolf]

In CbB (wahtever the latest is) it doesn't poof, AFAICT, (but the identical actions  / tests in the old SONAR on the same test laptop does poof) so it's something about how the older SONAR handled buffering.   

I'll probably just have to avoid using the loop/AS in any projects I'm using MM in. 

[Variorum]

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.

Edited Friday at 03:28 AM by Variorum

[Amberwolf]

Yup, that fixed it!

Thank you very much.

[Dave Schreier]

Hi Variorum -

When using CSMultiCompanderV2 for velocity, I see the orangish vertical lines indicating each note's velocity on real-time midi input, but not on playback of the track.

[Variorum]

1 hour ago, Dave Schreier said:

I see the orangish vertical lines indicating each note's velocity on real-time midi input, but not on playback of the track.

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. 😬

[Dave Schreier]

20 minutes ago, Variorum said:

Hey Dave... The note indicators are really just to give you some help if you're adjusting the response curve of your keyboard...

Very Interesting... Still very useful and thank you.

[Craig Anderton]

On 7/25/2024 at 6:08 PM, Variorum said:

As far as I know, Reaper is the only other DAW that supports DirectX plugins,

There's a wrapper I've been using for years that does a great job with making DirectX plugins look like VSTs. There's an issue with sidechaining, but other than that, it works well. 

1. Go to https://www.xlutop.com/buzz/zip/
2. Download the zip file dxshell_v1.0.4b.zip
3. Extract it, then copy the files dxshell.x64.dll and dxishell.64x.dll to the folder location where your DAW looks for VST plug-ins.

[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.

Edited yesterday at 04:33 PM by Variorum
OCD