16 channels humanizer optimization

General Discussion about Plogue Bidule

Moderators: vincent@plogue, davidv, seb@plogue

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Fri Jul 14, 2017 1:27 pm

The main initial reason was that I wanted to try something optimised, and it felt like something only on note on events was more optimised that something constantly running like a oscillator. Moreover, in that case specifically, I want to randomize velocities that occured at the exact same time (all derived for a unique message). Since an oscillator works depending on time, I don't see how I can randomize velocities with it. Sure, I could alter the initial data, but it would be the same velocity for each note on, not a different one for each, right ?

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Sat Jul 15, 2017 3:24 am

I just realized I may have misunderstood your answers: were you suggesting that the discrete version would allow me to "fuse" my 16 pipes into one, or just that I should keep my current "split by channel" architecture and that using discrete would be beneficial, even times 16, because audio buffers wouldn't be transfered all around?

seb@plogue
Site Admin
Posts: 9593
Joined: Tue Mar 02, 2004 7:23 pm
Location: Montreal
Contact:

Re: 16 channels humanizer optimization

Postby seb@plogue » Mon Jul 17, 2017 9:54 am

Since an oscillator works depending on time, I don't see how I can randomize velocities with it. Sure, I could alter the initial data, but it would be the same velocity for each note on, not a different one for each, right ?


That would depend on both the frequency of incoming MIDI notes and the frequency of the Random oscillator. But yes, unless I add something that generates a new random value on a trigger, events occurring on the same sample would get the same deviation/velocity depending on transformation or assignment.

were you suggesting that the discrete version would allow me to "fuse" my 16 pipes into one, or just that I should keep my current "split by channel" architecture and that using discrete would be beneficial, even times 16, because audio buffers wouldn't be transfered all around?


Both are doable and will be more efficient with discrete, if it's easier to split into 16 to control parameters/etc then you should stick with it.

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Mon Jul 17, 2017 10:08 am

Both are doable and will be more efficient with discrete, if it's easier to split into 16 to control parameters/etc then you should stick with it.


Well, it's not easier, since I actually need replace 15 instances of a bidule when I make some changes, but I really don't see how it is doable to have everything in the same pipe... obviously, it would be 16 times less work to change stuff and make fine tunings, but currently no modulation whatsoever seems possible this way... the activity or change bidules are seeing correctly the 16 events (ONLY if i've delayed them by 1 sample each) but discrete modulation bidules only send 1 trigger... Do you see a way randomizing 16 simultaneous note on's velocity is doable in only one pipe ?

Wouldn't it actually be faster for me to code my own bidules using the Bidule SDK ? I actually have some experience with C# and C++, wouldn't that be more efficient in the end ?

seb@plogue
Site Admin
Posts: 9593
Joined: Tue Mar 02, 2004 7:23 pm
Location: Montreal
Contact:

Re: 16 channels humanizer optimization

Postby seb@plogue » Mon Jul 17, 2017 11:05 am

I can get the discrete MIDI Activity to output 17 events on the same sample index if there are 17 incoming MIDI events. So I'm not sure why you don't get that. However there is definitely an issue with the Note Extractor 2 not outputting the Note On triggers on the correct index but none are missing.

You can't modulate a parameter in a precise manner even with discrete, hence why I was referring to applying an operation/changing the value of each discrete event coming out of the Note Extractor 2 before feeding Note Creator 2 but given the note on trigger thing that might be throwing you off into not thinking it work correctly.

But yes in the end, if you know how to code, it will always be faster/easier/give you more options/control to do it in code.

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Tue Jul 18, 2017 4:53 pm

Actually, I'm using the message extractor, it's the only way I found to easily deal with channel issues, since they can easily be passed over without having to rearrange them afterwards.

I ended up finding a "semi-hack" that works quite well, which is to use a shuffled value list which gets shuffled each time the wraparound trigger kicks in.
I've attached a small screenshot of the quite simple setup in the end. The discrete value coming in is the max added velocity, while the midi have been previously filtered to send notes on only.

On the optimization front, the non discrete version was adding something like 7-8% DSP, while this one is adding... nothing.
So I'd love to see a discrete plug in version soon, obviously :p. Because the setup is actually not working right now, the virtual midi cable trick that I had to do preventing Cubase from actually rendering any sound...

Now for the big chunk: how to convert my graphical envelopes modifying pitch upon note on into something discrete... If anyone has any idea, I'll happily listen...
Attachments
Vel humanizer discrete.PNG
Vel humanizer discrete.PNG (38.76 KiB) Viewed 572 times

jersmi
Posts: 3412
Joined: Tue Apr 19, 2005 4:18 pm
Location: Oakland, California

Re: 16 channels humanizer optimization

Postby jersmi » Tue Jul 18, 2017 11:32 pm

Plougot wrote:I ended up finding a "semi-hack" that works quite well, which is to use a shuffled value list which gets shuffled each time the wraparound trigger kicks in.
I've attached a small screenshot of the quite simple setup in the end. The discrete value coming in is the max added velocity, while the midi have been previously filtered to send notes on only.

Cool....



Plougot wrote:Now for the big chunk: how to convert my graphical envelopes modifying pitch upon note on into something discrete... If anyone has any idea, I'll happily listen...

(Forgive if you said this already) are the graph envelopes modulating pitchbend? If so, seems you'd have to use something close to audio rate for a smooth ramp (discrete to audio and back, for ex.). Otherwise, why not try a setup converting your graph env to a list?

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Wed Jul 19, 2017 4:54 am

(Forgive if you said this already) are the graph envelopes modulating pitchbend? If so, seems you'd have to use something close to audio rate for a smooth ramp (discrete to audio and back, for ex.). Otherwise, why not try a setup converting your graph env to a list?


Yes, the graph envelopes are modulating pitchbend upon note on, which gives, on a full string section, a really realistic attack, as players usually are a bit off initially and "harmonize themselves" afterwards, hearing each others. (Of course, you have to have individual strings like SWAM's ones, and a big computer to handle everything...(Currently drooling over Ryzen Threadripper))

The thing is, I'm having a hard time determining how to optimizing this with discrete. I know I can easily convert things, but the point is precisely to do it as little as possible. Moreover, I don't know what is the impact of modulating parameters on performances, and this information can be decisive in structural choices (for example, is it better to have several envelopes with an output selector above sending trigger to only one, or one envelope switching presets by modulation ?) (If you have any input on this one, seb, I'll be immensely thankful ^^)
And would discrete actually optimize anything ? If the major thing slowing down everything is my calculations, then yes, but if it's the envelopes themwelves, then no...
Anyway, more testing, more testing, more testing!

seb@plogue
Site Admin
Posts: 9593
Joined: Tue Mar 02, 2004 7:23 pm
Location: Montreal
Contact:

Re: 16 channels humanizer optimization

Postby seb@plogue » Wed Jul 19, 2017 9:49 am

Moreover, I don't know what is the impact of modulating parameters on performances, and this information can be decisive in structural choices (for example, is it better to have several envelopes with an output selector above sending trigger to only one, or one envelope switching presets by modulation ?) (If you have any input on this one, seb, I'll be immensely thankful ^^)


The actual changing of parameter values is negligible, it's what you are using to calculate the modulation that can be costly. The Envelope will always go through the the entire Trigger input and see if there's a trigger in there, it will also always output the last point of the env. So having a single envelope with presets would be better CPU-wise.

Since pitchbend has only 16384 possible values, you might get better performace out of discrete to audio, by multiplying and rounding/ceiling/flooring the envelope output so it has the pitchbend real range and discrete events are only created when there's an actual change that will change the pitchbend.

I'd need to look into what it would take to have a discrete version of the envelope (i.e. it would only output integers from a given min/max), not sure how much better it would be cpu-wise as it would still need to always "run" at sample rate internally.

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 20, 2017 6:03 am

Thx for the explanations ! I'll see what I can come up with.
About the one-sample-delay trick, I'm afraid the couple message creator & extractor needs it as well. I only get my 16 messages in output if I delay midi messages by one sample.

jersmi
Posts: 3412
Joined: Tue Apr 19, 2005 4:18 pm
Location: Oakland, California

Re: 16 channels humanizer optimization

Postby jersmi » Thu Jul 20, 2017 12:26 pm

I'm not digging in too deep here, but another suggestion if you are deciding not to go the SDK route would be to have a look at the polyphonic adapter for generating random velocities across n notes. Not totally sure how that would play with discrete processing.

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 20, 2017 1:47 pm

Is it possible to have a look at the SDK ? It might allow me to have a better picture of the overall structure I need (and I might end up programming it too).
Also, is there a reason why there isn't discrete input and output selector ?

seb@plogue
Site Admin
Posts: 9593
Joined: Tue Mar 02, 2004 7:23 pm
Location: Montreal
Contact:

Re: 16 channels humanizer optimization

Postby seb@plogue » Fri Jul 21, 2017 8:42 am

Send me an e-mail and I'll send it to you.

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Fri Jul 21, 2017 8:53 am

Just stumbled on this thread : https://www.plogue.com/phpBB3/viewtopic.php?f=8&t=7212&hilit=selector
So... dts350z kinda saved my life here...
Why aren't these bidule by default in bidule ? Even just as groups, and not "officially" in the list. Discrete processing just became a lot more easy and straightforward with all these tools...

Plougot
Posts: 48
Joined: Wed Jul 10, 2013 12:51 pm

Re: 16 channels humanizer optimization

Postby Plougot » Fri Jul 21, 2017 8:57 am

Send me an e-mail and I'll send it to you.


Actually, I can only see the website on your contact profile, so I'm not sure how to contact you...


Return to “Bidule General”

Who is online

Users browsing this forum: Bing [Bot] and 2 guests