code module and reseting the data stream

stefan · 2 Sept 2005

Since it's a mono section and still connected to the output I don't think it SHOULD be reset. SM can not know if the module is fully dependant on input to be "active" or not, so the best way to reset the module should be to disconnect it's output. Does that work?

oddson · 2 Sept 2005

stefan wrote: ...the best way to reset the module should be to disconnect it's output. Does that work?

Not sure what you mean by disconnect; not sure if you got what I mean by 'reset'.

To be clear -- by reset I mean flush the signal data out of the array in the code. (Zero the array data -- this seems to be what happens in the above example if you click the multiplex switch.)

There's a couple of issues:

In my mind the select and multiplex components are roughly equivalent so the divergence in behaviour was unexpected. I'm wondering if it's intentional/desireable and I just don't get it or if it's a quirk or even a bug. I need to know because most of what I've been doing in SM revolves arround long delays.

Secondly, what if I want to flush the data out of a code module? What would be the most reliable way to do it. I would think a non-opertive multiplex component used just to get this result would be prone to breaking on new versions and would look pretty mysterious in the schematic.

Now I'm wondering whether 9.4n release notes mentioning some "switch" issue might be relevent.

stefan · 2 Sept 2005

oddson wrote: stefan wrote: ...the best way to reset the module should be to disconnect it's output. Does that work?

Not sure what you mean by disconnect; not sure if you got what I mean by 'reset'.

To be clear -- by reset I mean flush the signal data out of the array in the code. (Zero the array data -- this seems to be what happens in the above example if you click the multiplex switch.)

Yes, I understood that. You basicly want the code to go back to stage 0. This should only happen when it's initialized as part of a mono section.

I was hoping this would work by using a selector on the output of the code module and for a brief while "deselecting" the output, so that the output of code module isn't connected to anything any longer. Then it should reset when being reconnected again.

oddson wrote: There's a couple of issues:

In my mind the select and multiplex components are roughly equivalent so the divergence in behaviour was unexpected. I'm wondering if it's intentional/desireable and I just don't get it or if it's a quirk or even a bug. I need to know because most of what I've been doing in SM revolves arround long delays.

Indeed, to me it seems strange that it resets at all just because you're using a multiplexer on the input side. Might need to investigate that, but as far as I can tell, resetting the code module should be done on it's output side, not it's input side, so this weird behaviour shouldn't really be a problem for you. Not at the moment atleast 🙂

oddson wrote: Secondly, what if I want to flush the data out of a code module? What would be the most reliable way to do it. I would think a non-opertive multiplex component used just to get this result would be prone to breaking on new versions and would look pretty mysterious in the schematic.

Disconnect the output and then reconnect it, do this by using a selector. If I'm wrong, please tell me. But I think this should work.

oddson · 2 Sept 2005

stefan wrote: ... it seems strange that it resets at all just because you're using a multiplexer on the input side.

Results are the same on the output side. And it didn't seem to matter if the connecters went anywhere but I can't swear on that without some further testing.

I'll test some more tomorrow... it's 12:30 at night here and the wife's asleep in the same room so I can't turn the speakers back on. Shh!

(at whisper volume) thanx 🙂

stefan · 2 Sept 2005

Yeah I just gave it a try. And disconnecting the output with a selector does _not_ reset the code module.

I expected it to do, and I think this probably is a bug.

What's interesting though is that the code stops running when being disconnected. So if I have it connected, play something on the synth, disconnects the code before the delay has sounded I can wait just as long as I want to, and then when reconnecting it, the delay will feed out what I played earlier. Heh 🙂

Jorge? 🙂

jorge · 2 Sept 2005

Hi Oddson

Both the selector and the multiplexer used to stop all the processes that are already playing, the selector was changed to work in a better way, the multiplexer will very soon be updated to behave like the selector.

oddson · 2 Sept 2005

That's what I was hoping for ...

But it leaves part two of my question: How can I get this result when it is what I'm looking for.

Sometimes I want to be able to clear the stream with a button click - but I figured doing it with the multiplex was not the best way.

jorge · 2 Sept 2005

oddson wrote: That's what I was hoping for ...

But it leaves part two of my question: How can I get this result when it is what I'm looking for.

Sometimes I want to be able to clear the stream with a button click - but I figured doing it with the multiplex was not the best way.

I hadnt thought of a component for stopping all the current sound processes but it should be quite easy to implement if it is important. Basically it would have a trigger input and no outputs, every time it receives a trigger it would stop all the currently running sound processes.

oddson · 2 Sept 2005

It's not important. 🙂

I was thinking there was a coding solution for the problem until I stumbled across this anomoly. I'll look at that again. It's not a major thing.

oddson · 2 Nov 2005

The multiplexer still does this... (clears the stream data unlike the selector)

And I've changed my mind about a component to intentionally interupt the data streams. My long delay projects would be very much improved with a 'reset' to clear the delays. (Since my base delay is built for 20 seconds it's rather a bit much to turn the feedback down and wait.)

Would it be possible to see such a component in some future release?

angstrom · 27 Jun 2006

oddson wrote: My long delay projects would be very much improved with a 'reset' to clear the delays. (Since my base delay is built for 20 seconds it's rather a bit much to turn the feedback down and wait.)

Would it be possible to see such a component in some future release?

bump

[+1]

angstrom · 27 Jun 2006

boo hoo, I hoped this 'bug'was still in existence and I could clear my delays

but it isn't , it has been 'fixed'

🙁 🙁 🙁 🙁

oddson · 27 Jun 2006

jorge wrote: I hadnt thought of a component for stopping all the current sound processes but it should be quite easy to implement if it is important. Basically it would have a trigger input and no outputs, every time it receives a trigger it would stop all the currently running sound processes.

Yeah... me too/still.

oddson · 1 Sept 2006

bump... Angstrom got his hard sync feature. Add this and he'll be a very happy camper! 😀 😇

oddson · 25 Jan 2007

jorge wrote: oddson wrote: That's what I was hoping for ...

But it leaves part two of my question: How can I get this result when it is what I'm looking for.

Sometimes I want to be able to clear the stream with a button click - but I figured doing it with the multiplex was not the best way.

I hadnt thought of a component for stopping all the current sound processes but it should be quite easy to implement if it is important. Basically it would have a trigger input and no outputs, every time it receives a trigger it would stop all the currently running sound processes.

...bump...

I've gone back to playing with my early Frippertronics style effects and a reset would really be nice to clear out the delay without having to wait up to 20 seconds for my mega-delay module to clear itself.

unkargherth · 14 Apr 2007

Maybe i didn't understood it all, but...

Wouldn't be simpler to add a trigger input in you delay that, when it's true, stuff zeroes on output unconditionally ? this way you getinstant zero output while feedback path clears at audio rate

angstrom · 14 Apr 2007

I tried this method, it's not workable unfortunatley

Its very hard, because in addition to the output attenuation there is the de-activation of 'rewriting' IE feedback of the audio to produce the loop.

the feedback needs to be 'off' for the loop period, and this would be accomplished by attenuating the output from the buffer audio (as you say) - but during that time new information (audio) is being added which does require repeating.

for example I play guitar into a two bar loop, but play a bum note, so I hit delete at the then of the two bar loop and begin to play the section again. That second version would be required to be recorded somewhere, but buffer 1 is busy being wiped.

Which means we now need two buffers and to switch between them, so that when we hit 'delete' we write 0 to the old buffer for the duration of a loop length (we need a switch timer set to 'loop length for this) . we delete that in real time and at the same time we switch recording over to a new buffer.

So now we need logic to deal with when we delete from 'buffer 2' and go back to buffer 1, flip flop. Which sounds simple, but provides complications.

.. it became like logic spaghetti dealing with issues such as - when the user changes loop length ,or when the user deletes twice in a loop length (it switches back to a non-empty buffer)

etc etc.

I do have a working solution which doesnt use the code window and uses the MEM component and some hackery. If anyone wants it for a looping project then let me know. I'm a bit hesitant to post it here as I will release it one day.

MichaelBenjamin · 18 Aug 2007

just stumbled upon that problem, so multiplexer code reset bug still persistant in 1.0.7 greetings michael

oddson · 18 Aug 2007

It's a long fixed bug... the thread was last about a replacement to that buggy behaviour which was also added. It's the 'Clear Audio' primitive.