problems with using a gen counter as an accurate trigger
I had been using [metro 1] to count milliseconds, but there were certainly moments when it would cut the signal off early or late, so I switched to triggering with a gen counter. The problem is essentially the same now, gen is counting in milliseconds, and sending bangs out, which I believe the subsequent (max) counter is mishandling. It's hard for me to isolate the example, it is the timing element of a speech synth I am working on, so it takes in the duration of the part of the word, and sends out a bang when the time has elapsed. The counter outside of gen is being used to count through the parts of the word, and when finished, it triggers the next. Does anyone have any advice on how this might be improved upon? Is there a way I could handle that second counter within gen?
If a coll receives 2 integers in succession too quickly, does it just skip?
As an exercise I tried to make [counter] inside [gen~].
This might be a problem anyway if you need to change to a Max message to access a coll.
But I'm not sure what the problem is in your patch without knowing the rest of the story.
Have you experimented with [count~] yet? I believe most of your timing problems are coming from mixing signal objects with non-signal ones.
I can't seem to put count~ somewhere useful in this, but yeah, I would say that the problems are from signal and non-signal level priorities, and getting something, from what I understand, as rigid as a signal level output, to translate to a max message trigger can come with some issues with synchronizing. I'm thinking occasionally the gen counter is outputting at an interval that the counter (or the coll) can't keep up with.
Very likely on the priority thing.
What's the coll storing exactly?
If your coll contains numbers, drop them in a buffer~ and then you can access them at signal rate.
Thanks Rick (and sorry for the delay, became massively busy the last week). I think this solution would work well, I was curious though, for a coll with multiple lines, should that translate into multiple channels? And if so, is there a way that you know of to change the number of channels in the buffer on the fly? I suppose I could set the number of channels high enough that I won't exceed it, rarely does this particular coll go beyond 10 - 20 lines.
Did a check, you can set the number of channels with "sizeinsamps" with the second argument.
"sizeinsamps 1000 12" will set a buffer of size 1000 with 12 channels.
("size" can also be used to set in milliseconds. ha..)
Either message will clear the buffer, so you might be better off just setting the maximum amount of channels you need.