Units which you might find useful are [env~] and [bonk~]
The [env~] unit returns the RMS level of the current audio block, which may be followed with a comparator.
[bonk~] is far more sophisticated, returning a float representing the weighted spectral change of the input according to a template or accumulated profile. It's used specifically for realtime beat detection.
In both cases the result is a control rate message (bang or float) which can be used to fire off a new message, either explicit or by dollar substitution, to create your ramp.
dear list members,
i am currently porting some max granular patch of mine to pd, where one object gives me some trouble. i am now looking for the function in pd of triggering a linear ramp with a audio signal (resp. click), with the ability of controlling the speed of the ramp also with a signal. i know that there is an rampsmooth port, but this one takes only messages for the rampspeed.
anyone can help? btw., platform is windows and linux...
thanks in advance,
micha
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
ok, sorry. i forgot to mention that the outgoing ramp should be a signal to. no conversion to the schedule in between, as i am used to do everything at signal rate for tightness and as a time wasting hobby.
scheme:
impuls/click generator (triggers a grain) -> polyphonic rampgenerator -> sampleplayback via buffer/table
what's the best way to do this in pd?
micha
Units which you might find useful are [env~] and [bonk~]
The [env~] unit returns the RMS level of the current audio block, which may be followed with a comparator.
[bonk~] is far more sophisticated, returning a float representing the weighted spectral change of the input according to a template or accumulated profile. It's used specifically for realtime beat detection.
In both cases the result is a control rate message (bang or float) which can be used to fire off a new message, either explicit or by dollar substitution, to create your ramp.
Hallo, Micha Thies hat gesagt: // Micha Thies wrote:
ok, sorry. i forgot to mention that the outgoing ramp should be a signal to. no conversion to the schedule in between, as i am used to do everything at signal rate for tightness and as a time wasting hobby.
You can get sub-sample tight timing in Pd by using [vline~]. I'm a bit short on time ATM, but attached is an example (I can explain it to you Friday. ;)
vgrain~-help.pd is the patch to open, then open a soundfile with [op] in sf-gui, switch on the metro and play with all the number boxes. You can ignore errors for Memento-objects and Scope~, the core functionality is implemented in pure core Pd.
Frank Barknecht _ ______footils.org_ __goto10.org__
hello frank,
thanks for the answer which is quite helpful. i already thought about using vline~, but didn't had a closer look at it. one reason is that i wanted to avoid the message level at any cost, because all this message timing and pre-microsequencing makes granular synthesis (and basically almost everything) unnecessary complicated.
and you're right, rampsmooth~ is message based, this is why i wrote some java external which triggers a defined ramp upon a click, all on the signal level, with some extended modes. this made my life so much easier, i can't understand why such a thing isn't implemented in max or why there is no external doing that kind of stuff.
one workaround would be, to multiply the ramp generated by rampsmooth or any other linear ramp generator and then clip it. the problem with that is obvious, you can make the ramp only faster and can't retrigger it for a fixed time.
another solution would involve some signal accumulator (btw, what is it called in pd?) and summing up the delta values. in max the +=~ is not resettable by a signal, so i went for my own external.
unfortunately i am no good c programmer, so i could have now ported it easily. the code in java is extremely short and i can give it to you off course.
well, looking forward to exchange some ideas tomorrow, would be nice if you can make it...
micha
Hallo, Micha Thies hat gesagt: // Micha Thies wrote:
thanks for the answer which is quite helpful. i already thought about using vline~, but didn't had a closer look at it. one reason is that i wanted to avoid the message level at any cost, because all this message timing and pre-microsequencing makes granular synthesis (and basically almost everything) unnecessary complicated.
and you're right, rampsmooth~ is message based, this is why i wrote some java external which triggers a defined ramp upon a click, all on the signal level, with some extended modes. this made my life so much easier, i can't understand why such a thing isn't implemented in max or why there is no external doing that kind of stuff.
(Maybe we can port it to C later...)
There is a set of externals by Eric Lyon which does something similar. He presented it at the Linux Audio Conference this year, paper and slides are here: http://lac.zkm.de/2006/proceedings.shtml#eric_lyon
Unfortunately I think, he didn't yet find the time to properly package and publish the code. Eric, do you copy? Is the source available already? But you may contact Eric at eric.lyon@manchester.ac.uk
The t3-objects in Iemlib are similar, but they get their triggers from messages, so they aren't too different from what [vline~] offers as builtin object.
Still personally I think, that [vline~] if used somehow like in my example patch can be quite powerful for granular stuff, and actually I don't think it's that complicated to use. But of course this also is a matter of taste and of how someone is used to work. I also have a phasor~ based granular patch I did somewhere here on this disk, which is much more difficult to read than the [vline~] solution in my view. At least it took me much longer to put together than the [vgrain~] which I just quickly hacked together yesterday evening. ;)
Frank Barknecht _ ______footils.org_ __goto10.org__