16 channels humanizer optimization

General Discussion about Plogue Bidule

Moderators: vincent@plogue, davidv, seb@plogue

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 9:02 am

Use bidule.support _AT_ plogue _DOT_ com

JensJohansson
Posts: 42
Joined: Sun Nov 04, 2012 10:48 am
Contact:

Re: 16 channels humanizer optimization

Postby JensJohansson » Fri Jul 21, 2017 1:03 pm

Plougot wrote: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 ?


I had some very similar ideas and problems. Bidule and this "interconnected graphical object metaphor" development is absolutely fantastic for 99.9% of things. But sometimes when you try to sort out the remaining 0.1% of the possible things, it can get very hairy to do stuff with processor objects connected with wires.

I definitely recognize the smell of that 0.1% in this particular problem too.

I had the exact same line of thought and also had a look at doing things at the SDK level, for stuff that is much more suitable to do in some procedural fashion.

In the end I discovered JesuSonic from the Reaper team, which runs as a VSTi under Windoze. It has a small development IDE in the VST GUI and I can write programs on the fly, which suits my "not infinite monkeys typing at random, just one monkey" coding paradigm perfectly.

Regarding some massively parallel / random intonation orchestral simulation, I have thought about doing something exactly like this as well. It's still on my very long to-do list. Mow the lawn. Get car fixed. Test pitch aspects of massively parallel orchestra simulation idea. Buy milk. Try to sleep some. Etc

Anyway I would implement these pitch variations as controlled by MIDI events. I would do something like this; take the raw "staircase" pitch value from the midi events, and filter them a la the ideas in this paper:

https://staff.aist.go.jp/m.goto/PAPER/W ... saitou.pdf

Then you output the midi note, subtract that from the filter output, and render the residual pitch as appropriate pitch bend messages periodically. This would give you preparation, overshoot and vibrato more like with an actual instrument. Obviously with a violin or viola the time constants might have to be adjusted.

You just loop this over every channel you want and of course you randomize the time constants a little bit. Obviously if you change the algorithm you don't need to edit this in 16 or whatever places ; )

If you're on Apple machine then there is no Jesusonic option. Then it's the SDK or Native Bidule objects. There will be some clever way to make those work as well.

JensJohansson
Posts: 42
Joined: Sun Nov 04, 2012 10:48 am
Contact:

Re: 16 channels humanizer optimization

Postby JensJohansson » Fri Jul 21, 2017 1:27 pm

BTW here is an example of synthetic preparation/ overshoot/ vibrato, in synthesis of the human voice. So, at least it's possible, and the results might be OK.

prep, overshoot, vibrato ex.zip
(5.97 MiB) Downloaded 16 times


I didn't make it, and I forget where i found it now....

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

Re: 16 channels humanizer optimization

Postby Plougot » Wed Aug 02, 2017 12:00 pm

HiJensJohansson! Thx for the long reply!
Actually, I don't need to emulate that much of a player, my virtual instrument (Swam violin) is already doing some randomization for me (I need to recreate variations, but not full humanization), even though it is still interesting. However, I think it applies more to voices than to string instruments. I Might still get some inspiration from it if I decide to code my way out, so thank you very much!

@seb : I tried to go back to the plugin version, but realised my whole setup is based on features (mainly shuffled indexed lists) which came AFTER the last discrete vst build, so... Would it be possible to have it ? ^^

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

Re: 16 channels humanizer optimization

Postby jersmi » Wed Aug 02, 2017 3:22 pm

JensJohansson wrote:preparation, overshoot and vibrato


I appreciate this thread, and also feel it's value moving forward. (Though doesn't preparation by definition suggest needing to look ahead to know how to "prepare" before a Note Off happens? Wouldn't this require some analysis of a pre-existing midi file, i.e., not real-time?)

Currently I have something going using built-in Bidules. It's a simple concept, one table modulating pitchbend to achieve both overshoot and vibrato. I'm thinking dsp% can be conserved using one Accum driving multiple lookup tables (or Graphic (Basic) envelopes), one per channel or whatever.

Screen Shot 2017-08-02 at 1.44.26 PM.png
LUT for pitchbend overshoot and vibrato
Screen Shot 2017-08-02 at 1.44.26 PM.png (18.84 KiB) Viewed 369 times

I would prefer to use graphic envelopes instead of the LUT, and in fact this may require it in the future because of the limits of the LUT, but the Bidule envelope UI frustrates me, to put it kindly. That aside, Seb -- do you think this idea of having one Accum driving multiple LUT's or Graphical (Basic) envelopes would conserve dsp%?

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

Re: 16 channels humanizer optimization

Postby jersmi » Fri Aug 11, 2017 1:09 am

seb@plogue wrote: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.

Hi Seb -- there is really something to this post, would love to have a low dsp% graph. Have you given it any thought?

What about an envelope for both discrete and standard that does not process until some timebase/counter tells it to? This idea would be to allow one timebase to drive many envelopes.

For example, I've started putting together a discrete group that uses Value Lists (it's the only discrete option available), but the roadblock is how to generate lists of gestures. If I figure out a way to generate some lists, I think it would perform pretty well. Using a fast timebase still kind of sinks the ship with discretes, so we'll see.

On the non-discrete side, Bidule has the map, graphical envelope, LUT, Accum + math, lists, maybe the audio buffers, even the indexed multi-sliders for "low res" stuff. Could there be one solution that's sort of a best-of update, a combo of a graphical envelope, LUT and map? Actually, this is sounding like a request for something like a recordable automation envelope that comes with most DAW's.... that is, easy to edit/re-edit, writable like the map, does not process until driven by an external timebase, can "manually" step through the envelope (with a playhead, key combo or whatever), can set range in the graph.

Thanks for listening!

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

Re: 16 channels humanizer optimization

Postby jersmi » Sat Aug 26, 2017 6:54 pm


JensJohansson
Posts: 42
Joined: Sun Nov 04, 2012 10:48 am
Contact:

Re: 16 channels humanizer optimization

Postby JensJohansson » Wed Sep 27, 2017 10:28 am

jersmi wrote:I appreciate this thread, and also feel it's value moving forward. (Though doesn't preparation by definition suggest needing to look ahead to know how to "prepare" before a Note Off happens?


Indeed, this is why we need some sort of plugin that bends spacetime so we can prepare for things that haven't happened yet.

jersmi wrote:Wouldn't this require some analysis of a pre-existing midi file, i.e., not real-time?)


I think this is the approach of the people who made that sound file yes. I was thinking for live use you just take care of the "anticipation" by adding a small delay which your mind then compensates for when you are playing ..

jersmi wrote:Currently I have something going using built-in Bidules. It's a simple concept, one table modulating pitchbend to achieve both overshoot and vibrato. I'm thinking dsp% can be conserved using one Accum driving multiple lookup tables (or Graphic (Basic) envelopes), one per channel or whatever.


This looks like an interesting approach actually. I saw that other thread!

jersmi wrote:I would prefer to use graphic envelopes instead of the LUT, and in fact this may require it in the future because of the limits of the LUT, but the Bidule envelope UI frustrates me, to put it kindly. That aside, Seb -- do you think this idea of having one Accum driving multiple LUT's or Graphical (Basic) envelopes would conserve dsp%?


I think you could also experiment with thinning out the density of the pitch data. Depending on the instrument there may be some built in slewing of the PW pitch anyway. And also depending on the sound/ context/ music the ear might not be as sensitive as you think ..

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

Re: 16 channels humanizer optimization

Postby jersmi » Sat Oct 14, 2017 3:02 am

JensJohansson wrote:Indeed, this is why we need some sort of plugin that bends spacetime so we can prepare for things that haven't happened yet.

Feature request! :mrgreen:


Return to “Bidule General”

Who is online

Users browsing this forum: No registered users and 4 guests