Tim Lloyd

Been trying to figure this out for a while with no luck.

Its an attempt at making an abstraction which is similar count~, tap.count~ etc... but unlike those, is turned on/off at signal rate and also has it's length/count modulo set at signal rate.

The patch is commented if anyone feels like having a go!

(it's a little annoying that count~ and co are not fully signal controllable already, as they seem to be made for use when accuracy is important)

up-for-a-challenge

I should have mentioned, the accumulate~ external can be downloaded from here:

i have no max here now, but it is interesting enough 

i have no max here now, but it is interesting enough 
to look at it later.

Well, I've found phasor~ to be no good for use with index~/poke~ in my patch, as it causes glitches during playback and recording, even with trunc~. It also suffers from no option to reset phase with a signal.

A signal-reset-able phasor~ would be useful, it's just a matter of dividing the output of %~ by the length of the ramp to create a 0-1 ramp like phasor, which would then be able to be reset to 0-phase at signal rate.

What I really need to do is create these things in whatever code is needed to compile externals. alas......I cannot...yet

Well, I've found phasor~ to be no good for use with index~/poke~ in my patch, as it causes glitches during playback and recording, even with trunc~.  It also suffers from no option to reset phase with a signal.

What I really need to do is create these things in whatever code is needed to compile externals.  alas......I cannot...yet

timlloyd wrote on Tue, 25 August 2009 10:54

don't know about a "max-only-solution", but i believe there are a few externals floating around that do what you want.

i have also done one some time ago, when i needed similar functionality. see the attachment if you are interested (osx only, though). maybe this is what you need.

timlloyd wrote on Tue, 25 August 2009 10:54
A signal-reset-able phasor~ would be useful, it's just a matter of dividing the output of %~ by the length of the ramp to create a 0-1 ramp like phasor, which would then be able to be reset to 0-phase at signal rate.

don't know about a "max-only-solution", but i believe there are a few externals floating around that do what you want.
i have also done one some time ago, when i needed similar functionality. see the attachment if you are interested (osx only, though). maybe this is what you need.
vb


Your vb.ramp~ is soo close to being exactly what I need all in one object.

As it is a one-shot ramp, I have to now figure out how to cascade a few of them so they can trigger eachother to create a looped ramp.

How difficult would it be to modify the code so it loops the ramp time length until either the ramp time is changed or the left inlet receives another zero to non-zero transition trigger?

I just noticed that vb.ramp~ seems to trigger on a non-zero to zero trnsition, when sig~ is connected to the left inlet rather than a click~.

It is almost the same as the cshot~ external I was trying this with last week (not sure who made it), and both have the problem that they don't loop their output ramp.

It seems like the perfect object for this would be a cross between your vb.ramp~ and vb.phasor0~.

well, it loops if you send regular clicks, e.g. generated from a phasor~. possibly not what you are looking for.

can be triggered by a signal and has a loop mode.

in certain situations i've found it to be slightly inaccurate, though.

well, it loops if you send regular clicks, e.g. generated from a phasor~. possibly not what you are looking for.
but, have you checked out zigzag~?
can be triggered by a signal and has a loop mode.
in certain situations i've found it to be slightly inaccurate, though.


Yeah, zigzag~ is yet another slightly irksome msp object. It will loop, and the ramp can be triggered by a signal, but only in mode1, and this signal use of the left inlet means that the length of the ramp can no longer be set by a signal. Unless I missed something when reading the reference file.

Any suggestions on my original question? I'm interested to see how complex it is to achieve inside msp.

Yeah, zigzag~ is yet another slightly irksome msp object.  It will loop, and the ramp can be triggered by a signal, but only in mode1, and this signal use of the left inlet means that the length of the ramp can no longer be set by a signal.  Unless I missed something when reading the reference file.

Any suggestions on my original question?  I'm interested to see how complex it is to achieve inside msp.


timlloyd wrote on Tue, 25 August 2009 14:44

you could set the ramp with a message to [zigzag~] to something like [0 0 1 1000] before hand and control the speed of increase of the ramp by a signal to the right inlet. culprit here is that the speed inlet is only sampled once per signal vector.

might still not be what you're looking for.

timlloyd wrote on Tue, 25 August 2009 14:44Yeah, zigzag~ is yet another slightly irksome msp object.  It will loop, and the ramp can be triggered by a signal, but only in mode1, and this signal use of the left inlet means that the length of the ramp can no longer be set by a signal.  Unless I missed something when reading the reference file.

you could set the ramp with a message to [zigzag~] to something like [0 0 1 1000] before hand and control the speed of increase of the ramp by a signal to the right inlet. culprit here is that the speed inlet is only sampled once per signal vector.
might still not be what you're looking for.


I don't think that would work unfortunately. I need the looped ramp to control index~ and poke~ so slowing down would affect playback/recording.

I think the only solutions are either to figure out how to cascade a couple of your vb.ramp~ or the cshot~ objects, or how to reset accumulate when %~ reaches 0 in the other method.

I don't think that would work unfortunately.  I need the looped ramp to control index~ and poke~ so slowing down would affect  playback/recording.

have you tried doing it by using a counter~-generated buffer~?

buffer/play can be started by signal, do not need trunc (we

just create the "int" samples on load), can be shifted, reversed,

stopped in the middle and restarted sampleexact at any time ...

p.s. i can only participate when i get a max4 code, or a max5 .pat file.

buffer/play can be started by signal, do not need trunc (we
just create the "int" samples on load), can be shifted, reversed,
stopped in the middle and restarted sampleexact at any time ... 

p.s. i can only participate when i get a max4 code, or a max5 .pat file.
a little screenshot will also do.

Yes, the length of the ramp needs to be variable/dynamic.

I can't think how else it is possible without sticking to the basic idea of the patch I posted earlier:

I actually emailed Andy Schmeder fomr CNMAT a week or so ago about this, because he wrote the accumulate~ object. He said he would have a think about it, but I've not heard back yet.

I actually emailed Andy Schmeder fomr CNMAT a week or so ago about this, because he wrote the accumulate~ object.  He said he would have a think about it, but I've not heard back yet.


I made an absraction [wac.counter~] that uses a signal input to count samples (suitable for feeding [index~]).

The count maximum is also set by a signal. The output loops between 0 and the maximum.

There is no 'handling' for changing the maximum whilst the counter is looping, i.e. if the maximum is changed to some value lower than the current count it will no longer loop. I could never decide "how" i wanted to handle this so havn't implemented it yet...

Also, resetting the count to zero is controlled by a bang, not a signal....

Very nice, this seems to work how I need it to. I've not got much free time over the next 2 days, but I've thrown together a little patch with your wac.counter~ that seems to be working just right!

I'll have to have a look at how the abstraction works tomorrow evening, and optimize my mock-up patch. I'm not 100% sure that I've done it in the most accurate way possible.

My only concern is whether or not the send~/receive~ pair in wac.counter~ is affecting the accuracy of the signal in any way. I'll have a look at it later.

Very nice, this seems to work how I need it to.  I've not got much free time over the next 2 days, but I've thrown together a little patch with your wac.counter~ that seems to be working just right!

I'll have to have a look at how the abstraction works tomorrow evening, and optimize my mock-up patch.  I'm not 100% sure that I've done it in the most accurate way possible.

My only concern is whether or not the send~/receive~ pair in wac.counter~ is affecting the accuracy of the signal in any way.  I'll have a look at it later.

Investigating the 'accuracy' issue you mentioned, I found [wac.counter~] was looping 1 sample less than the specified maximum.

I have ammended the 'copy compressed' code in my above post to put an extra [+~ 1] object in there to fix it.

The send~/receive~ pair is to introduce a vectors delay; this is necessary for allowing the output of the [+=~] to be fed back into itself.

There is a dspstate object (that reports the current vector size) feeding a [- ] to compensate for the vector delay in the calculations.

up for a challenge?