Brian H.

I have this problem commonly, though I thought I'd pose it here:

I need to send a pile of unknown stuff into a patch; but before that, I need some clear/reset type messages for various objects. For example, send a series of lists (unknown length), but have the 1st of the series trigger 'clear' to [coll], reset [counter], 'zlclear', etc.

I've tried a few different approaches, without finding something that would really do the job. Any ideas how to do this in a reasonably reliable (and hopefully elegant!) way?

Hi,
I have this problem commonly, though I thought I'd pose it here:

I need to send a pile of unknown stuff into a patch; but before that, I need some clear/reset type messages for various objects.  For example, send a series of lists (unknown length), but have the 1st of the series trigger 'clear' to [coll], reset [counter], 'zlclear', etc.

I've tried a few different approaches, without finding something that would really do the job.  Any ideas how to do this in a reasonably reliable (and hopefully elegant!) way?

Hi,
I have this problem commonly, though I thought I'd pose it here:
I need to send a pile of unknown stuff into a patch; but before that, I

'clear'-puzzle···

Is there a way for your patch to 'understand' when the stream of data begins and/or ends?

One could use receive object like [r CLEAR-ALL]

and connect that to all objects which need resetting, or various messages , depending on

Then send a Bang to [s CLEAR-ALL] before the data stream starts.

I use something like that to clear the patches and objects before building standalones,

That should not be so difficult .
One could use  receive object like [r CLEAR-ALL]
and connect that to all objects which need resetting, or various messages , depending on
what they respond to. (clear, set etc)
Then send a Bang to [s CLEAR-ALL] before the data stream starts.

I use something like that to clear the patches and objects before building standalones,
sometimes there are many, many 


Yes, I'm looking for a way to know when the data stream begins, and to only act once at that time.

If I'm understanding the suggestion, what I need is a way to basically use something like [trigger], but only on once at the very beginning of the data stream. It seems like the [send/receive] approach wouldn't do that– it would clear every time it sees a new piece of data in the stream.

I tried using [thresh] to basically take the entire stream and get it into 1 giant list, solely for the purpose of firing [trigger] once. But I ran into making the timing reliable (avoiding using only R/L positioning), to make [trigger] fire before the rest of the data gets through...

Yes, I'm looking for a way to know when the data stream begins, and to only act once at that time.  

If I'm understanding the suggestion, what I need is a way to basically use something like [trigger], but only on once at the very beginning of the data stream.  It seems like the [send/receive] approach wouldn't do that– it would clear every time it sees a new piece of data in the stream.

I tried using [thresh] to basically take the entire stream and get it into 1 giant list, solely for the purpose of firing [trigger] once.  But I ran into making the timing reliable (avoiding using only R/L positioning), to make [trigger] fire before the rest of the data gets through...

what kind of data are we dealing with? just to understand..

This is primarily for lists. Ideally of all sorts, but just int/float is OK to just move forward with it.

This is primarily for lists.  Ideally of all sorts, but just int/float is OK to just move forward with it.

The main goal here is to know when to clear all objects, and not how to clear them.

So You have to declare what is the beginning of the data transmission.

If that is unknown, and no other parameter can be used, like pause between

data chunks which could be taken for end of stream / ready for new stream

The main goal here is to know when to clear all objects, and not how to clear them.
So You have to declare what is the beginning of the data transmission.
If that is unknown, and no other parameter can be used, like pause between
data chunks which could be taken for end of stream / ready for new stream
it will never work.


Bill, I think [onebang] may be it! I *thought* I recalled an object like it, but couldn't remember what it was called. My little scam with [thresh] completed the puzzle, I think. Try to abuse it, and see if it stands-up...

Bill, I think [onebang] may be it!  I *thought* I recalled an object like it, but couldn't remember what it was called.  My little scam with [thresh] completed the puzzle, I think.  Try to abuse it, and see if it stands-up...


Brian, I'm a bit confused about *exactly* what you're wanting to do. e.g. I can't see why you're using [thresh]. I suspect you're heading in a roundabout way to what the others have been asking/saying.

Do you want your patch to be reset once (i.e. ONLY once) when it first receives data, and then never ever again? If so, surely it's already reset/cleared when you open it...?

Or do you want it to be reset every time it receives the very first item in a new burst of data (after there has been no data for a while)? If so, then LSKA's first question and Source Audio's last post are exactly what I reckon you should be considering.

A [delay] and a [onebang] *might* be all you need, as in this thread from a couple of days ago: 

https://cycling74.com/forums/send-a-bang-after-no-more-numbers-are-being-received

Brian, I'm a bit confused about *exactly* what you're wanting to do. e.g. I can't see why you're using [thresh]. I suspect you're heading in a roundabout way to what the others have been asking/saying.

Do you want your patch to be reset once (i.e. ONLY once) when it first receives data, and then never ever again? If so, surely it's already reset/cleared when you open it...?

Or do you want it to be reset every time it receives the very first item in a new burst of data (after there has been no data for a while)? If so, then LSKA's first question and Source Audio's last post are exactly what I reckon you should be considering.

A [delay] and a [onebang] *might* be all you need, as in this thread from a couple of days ago: https://cycling74.com/forums/send-a-bang-after-no-more-numbers-are-being-received

Yeah, I think you're right about delay doing it. The patch in the thread you linked to was pretty slick. I was avoiding delays, because my gut feeling was that it might be unreliable. But thresh also uses timing, I guess. This is good stuff, thanks– something that is needed frequently.

Yeah, I think you're right about delay doing it.  The patch in the thread you linked to was pretty slick.  I was avoiding delays, because my gut feeling was that it might be unreliable.  But thresh also uses timing, I guess.  This is good stuff, thanks– something that is needed frequently. 

'clear' puzzle...