code module and reseting the data stream

[oddson]

It appears that engaging a select module in a project will not interrupt the stream of data coming from the code module but engaging the multiplex module will interrupt code stream.



In this example, sending a note and clicking the switch while the note is in the delay will stop the delay if it’s the multiplex switch but not if it’s the select switch.

And it doesn’t seem to matter if its pre or post code module.

Can anyone say why? Is it a bug or a feature? (I'm I missing something?):S

What else will reset the data in a code module?

[stefan]

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]

...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]

...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.

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

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]

... 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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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