has anybody ever done this?
any ideas on how to do that quick and efficient?
-
[line~] with audio-inlets
-
@lacuna [*~] + [line~]........ ?
Sorry, being a bit abrupt.
You need a message "to go to" and "in time".
You would need impulses ([sig~] would not work as you need a "moment to act"), and the second would have to be a very high value.
Why?
Do you want to wave shape?......
If so it can be done by calculation, and might now be out of patent...... F04.waveshaping.pulse.pd
David. -
Time and target of the ramp should get calculated and executed several times in less than the 64 samples-grid of the message-domain sheduler [sic]
I correct myself: like [vline~] with audio-inlets
-
my ideas, before starting to make it probably more clear:
what i would need:samplecounter to know when time is up
and low pass filter to shape the ramp?
or
samplecounter, calculate the ramp, do the ramp, time is upsomething like this? Probably there is already some abstraction for this or a really smart way to go?
-
@lacuna Concretely speaking, why do you need to start ramps multiple times within a 64 sample space?
-
@lacuna Maybe start with [phasor~] as you can know the number of samples for the ramp.
Can it ramp multiple times per block? Maybe a change of block size would be necessary, but maybe not with a signal rate input.
Obviously the smaller the samples length the greater the step size.
It will take a signal rate control if you don't specify an argument.
Inverting the ramp would need a [*~ -1], and changing the end values would need math functions as well, but they can all be signal rate.
I think any low pass filter would take the ramp well beyond 64 samples.
David. -
@whale-av yes, [phasor~] *is *a ramp! I will try ...
-
[vline~] can process different ramps inside of a block (whereas [line] and [line~] are bound to the block boundaries), and can even start and stop ramps in-between samples (cf. help file). So i guess that if you send the right message with the right succession of ramps, it's ok !