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

16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 4:53 am

Hi everyone !
I'm currently working on a humanizer which takes my midi input and transforms it into 16 slightly different midi streams, to mimick a string ensemble (Swam strings hosted by vienna ensemble pro).
I have already a setup running, with mostly 16 parallels lines, and the asio cost seems awfully huge (with it enabled, I can barely run 8 violins, whereas I'm at 16 with all the humanizer modules muted or bypassed... The DSP goes all the way above 100%, but the cpu doesn't cross 40-50%... So I was wondering if i could do some optimisations...
I started trying to get every going through one line instead of 16 splitted by channel ones... The thing is, I don't know how to use the channel number as an index on my 16 indexed variables, so that I can treat each messages depending on its channel... the channel extractor bidule only seems to be able to ouput one channel number (the last one) when 16 messages are arriving at the same time, which is the case here since they've been created from the same initial message. I know that technically they're not processed at the same exact time, but being in the same batch seems enough here to cause a problem.

I'll be happy to share further informations if anyone has any question.
Thx!
David

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

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 6:54 am

Okay, after some more testing, I can see my problem clearly. On a single buffer span, on a virtual midi wire, while midi messages can go throught, trying to extract channels or to do anything turning them into audio makes them collapse into one because, I guess, for one buffer, there is one output...?
Does this mean the only way for me to do what I want to do efficiently (duplicate and transform midi datas on the fly) is only achievable through the SDK ?

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

Re: 16 channels humanizer optimization

Postby seb@plogue » Thu Jul 13, 2017 7:10 am

You could look into the P2 version which has an additional signal type, discrete which could best be described as like MIDI but with numbers meaning that instead of having a MIDI message part going to audio rate, it will generate a single event with the possibility of having multiple ones occurring at the same sample inside a buffer.

Note however that not all bidules have a discrete version.

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

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 7:28 am

Thx for the reply seb!
The thing is, I need to use the VSTi version, since Cubase is a bit wonky with its Asio-Guard and everything, and I cannot break the "audio-line" if I want it to work properly. Meaning : I can't send my datas to something other than an instrument hosted by cubase. At least, I never managed to get anything working properly with external software, when it comes to rendering, freezing, etc...
And last time I checked, the discrete version was only for standalone, right ?

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

Re: 16 channels humanizer optimization

Postby seb@plogue » Thu Jul 13, 2017 9:58 am

I haven't built the plugin versions of discrete for quite a while because a) people didn't seem to use them and b) it adds a few hours to the build time

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

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 11:22 am

Would an hybrid approach be feasible, (like sending midi from the plug in version to the discrete standalone via virtual midi cables) or would I lose all the benefit from the discrete approach? Would it be completely transparent for my daw ?
Moreover, do you think my initial plan would end up with better performances ? Trying to have "one pipe with 16 times more midi messages" instead of "16 pipes with 16 times less" ?

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

Re: 16 channels humanizer optimization

Postby seb@plogue » Thu Jul 13, 2017 12:10 pm

Having not seen the layout, I'm tempted to think the performance issue is caused by going to audio/sample rate hence why I suggested taking a look if you could redo it with P2 and see what is the performance gain.

I don't think using a virtual MIDI port to go back and forth with the standalone is something that is useable in the end. However it definitely
could be used to build and test a P2 version of your layout and see if it fares any better.

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

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 12:34 pm

Ok, I'll test it out that way, then.

The layout is actually quite straightforward in its structure : a midi in converted into 16 streams for one channel each, then going through multiple layers of humanizers (velocity, random note on pitch enveloppes, global detuner, rnd delays...). I had to split by channel on occasions to avoid the "merged channel issue" discussed above.

The main thing is, most of the time, I had to use extractor / creator couples, to create new messages with the datas I wanted... I guess it's what might slow everything down.

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

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 2:19 pm

I've done some testing, it's pretty hard to conclude anything since I'm getting dropped notes all the time (or more precisely, some sort of "note offs leaks" : playing fast, it's as if the note off of the previous note is actually "killing" the next note right after it starts ringing...
Also, in the standalone P2 instance, i got "CPU overload" all the time, whereas the dsp is only at 20 on 1 core, my cpu at 40% on average, and the asio load at 70...
Do you think it's because the virtual midi cable is not up to the task ? I'm currently using loopbe30... I'll try some bome's midi translator virtual cables, I think they're supposed to be better optimised

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

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 3:01 pm

Nah, no matter what I do, even when i get rid of almost everything and have no more cpu overload, I still get dropped notes (one out of three on average), which makes it totally unplayable... I think that's why I began to use only the plug in version in the first place...
Which means... I'd really like to have a discrete version of the plug in :p ...
One more question : I'm modulating several parameters, and I don't see any discrete modulation bidule... Is it possible to modulate "discretely"?

I can assure you that while most people didn't use it until now (me including), if a setup like this was feasible, a lot of people would find it useful. A VST host capable of fine midi humanizing features is critical for really precise modelling instruments like Sample modeling's as soon as you do ensemble sounds, and since this kind of audio modeling or semi-modeling is clearly the future (even more so with the cpu competition rising again between intel and amd), this is only going to get more and more important.

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

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 3:33 pm

My bad, my bad, I had some silly wiring going on... It was not doing this before, but my project is a mess, so I may very well have done something silly while migrating to the discrete setup.

I still have some weird behaviours I have to investigate, though, especially on my "note on pitch random enveloppes", which seems to add quite a bit of latency when switched on... Maybe it's just too heavy and everything's getting "behind schedule" (notes are getting "forgotten" as well if I play too fast).
Another problem where I am still stuck is the modulation of parameters on a discrete basis... Sure, I can convert from audio to discrete, but isn't the whole point of this to be able to have discrete steps ?

EDIT: my bad again... it's easy to get lost in the menus... discrete modulations are NOT in the discrete subfolder, but in a discrete folder INSIDE the modulation folder ^^...

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

Re: 16 channels humanizer optimization

Postby Plougot » Thu Jul 13, 2017 4:31 pm

Advancing a bit, I'm encountering quite a similar problem than before... Since there were no discrete channel remapping and since the note Extractor was not extracting the 16 messages coming at the same time (which it should have done, if I've understood correctly how it should work), I decided to use message extractor and creator.
But I'm currently scratching my head against the same problem that with the non discrete version : I can't apply a different random value to each velocity. Why ? Because while the activity bidule sends 16 triggers, the modulator one seems to send only one modulation trigger. Or maybe he's sending them all at the same time, I don't know... The thing is: since the modulation needs to happen for each note, I was using the modulation trigger bidule, which is not available in a discrete version.
In the end, the result is the same as in the non discrete version: I can't get it to work the way I need it to (which is: ch1, rnd velocity, ch2, rnd velocity, ch3, rnd velocity)...

EDIT: Small precision : to make the message extractor and creator work, I had to delay each midi message by 1 sample more than the previous one. Is it normal ?

ZergFood
Posts: 111
Joined: Fri Aug 21, 2009 3:39 pm

Re: 16 channels humanizer optimization

Postby ZergFood » Fri Jul 14, 2017 6:23 am

seb@plogue wrote:I haven't built the plugin versions of discrete for quite a while because a) people didn't seem to use them and b) it adds a few hours to the build time
For what it's worth, I'd certainly use them, but well, I can't use what's not available ;)

I'm guessing an overnight build would solve the "adds a few hours to the build" or is that not feasible?

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

Re: 16 channels humanizer optimization

Postby seb@plogue » Fri Jul 14, 2017 8:19 am

But I'm currently scratching my head against the same problem that with the non discrete version : I can't apply a different random value to each velocity. Why ?


Is there any reason why you don't simply apply a +/-/* to the velocity instead of going through parameter modulation?
something like sampling (audio to discrete) a random osc running at a low rate?

I'll have to check the code for the other q's.

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

Re: 16 channels humanizer optimization

Postby seb@plogue » Fri Jul 14, 2017 8:19 am

For what it's worth, I'd certainly use them, but well, I can't use what's not available ;)


There's a 9740 link lost somewhere in the latest page.


Return to “Bidule General”

Who is online

Users browsing this forum: Yahoo [Bot] and 3 guests