Float array to Memin could restart , and selector....

[Tepeix]

Just find this trying to get some parameter from memin.

If you have a float array transformed in a mem, modifying the float array would restart or recompile all code.
Even code that are not attached to the code with memin will restart. Reinitializing variable and doing a stage(0)!

It could be bad !
In a other way, it could maybe be useful if some need to make some calculation at stage0.
But that must be when there's no sound. (Maybe when the sample rate change ?)

Changing the mem in a other way, writing on it on dsp doesn't do that.
It's only when changing the array in green float.

I was surprise to see that even code that are not connected to the one with memin would also restart.
So i get the idea to check for selector that bypass a code and it's a little different.

With those, all code that have a stage0 will do it. But variable that are not modified in the stage 0 keep the same.

That's maybe an indication that the selector will not recompile all the code of the plugin ?? ?
But that the float modify to memin do it ?

[Spogg]

I’m not sure I fully understand but when anything happens that needs a recompilation, like a float array to mem or a selector in the audio stream changes, the whole schematic will recompile and execute any stage(0) codes for the first sample only.
One way to force a recompile is to use the Clear Audio prim in the green world, as in the schematic.

The thing that really puzzles me is the packing section of your schematic. I solved that by changing xmm0 to xmm1 in stage(2) and I have no idea why that makes it work using the input selector. We need an ASM expert for this.

Of course I may have totally got the wrong idea about your points…

[adamszabo]

I have a hard time understanding the problem as well..

[Tepeix]

When i make the first code with memin, i wanted to get 8 value in stage0.
But i find that the float array restart the code so i do some test with it.
So your solution Spogg do the same in this case.
There's obviously no need to load more than 4 value
(( sorry i made a mistake of code, thinking that you modified the first one (see next post)))

I did not know that changing the array in float will restart the code so it was the main point.

But note that there's something different than a selector :

Maybe (or more probably) the selector will recompile all the code.
This could take time and do an interruption click (depending of the size of the plugin)

But in case of a float array to memin the click will be more intensive.
It will also be sure that it occurs.
(using this it's maybe possible to avoid the selector click : viewtopic.php?f=4&t=93160 But if the size of the plugin is big and the recompilation longer it will maybe not work..)

And that's because the selector only reset variable that are modified in stage0.
Most of time, we do not use so much stage0, and even if a stage0 is done the variable had some chance to not make click and not change so much, only recalculate. (depend of the use you make of stage0)

But in case of a delay, a filter, (and most process) if every variable is reset, you get a more pronounced click.
The index go back to 0, the memory reset, the feedback stop..

For sure, it doesn't change so much. Normally you get some click if you use a selector.

The click could only be more pronounced with float array, in case of delay the index reset could cause a more longer discontinuity.
For filter it will maybe be a click of the size of the filter latency ?


But the fact that there's no variable reset with selector give me a very little hope (maybe i'm wrong) that the selector do not really recompile all the schematics.
Maybe it have all code that could be selected in memory and only switch the path of the variable.
The click occur because the different code in the selector make an abrupt change.

Very possible that i'm wrong, but if the code recompile doesn't it need to reset and reassign all variable ?

...The thing is that i need a very large plugin to test it with a lot of code to be potentially recompiled..

Note that it's also possible to use some skip in asm to replace the selector with no click..
But it's not so much practical.. Making the code more complex..
Maybe it could be also possible to do a hack like the oversample in this topic : viewtopic.php?f=4&t=10397&hilit=oversample
(Even if i do asm, i'm afraid to go in the hack process to get some address code..
Also with the mem address.. Maybe one day i try..)

[Tepeix]

I doesn't see well the change you made Spogg.
(was thinking that the change was with the first code)

For the last code, it doesn't change change something to use xmm1 or xmm0.
Every cycle the code have to use some xmm.
variable are not reset, but xmm will always be every cycle.
(if you use xmm5 in a asm code you must first assign a value to it (from variable or other xmm)
if not the xmm could have the value of any other process that use it and not the last value of the present code.)

From my perspective, asm is not so hard and different to program than dsp, but the first thing that is a little confusing, is that you have to load any value inside a xmm then to proceed it with calculation; sometime we have to note which xmm do what or which value is stored where..

For the last code of my example, i go to another thing. (forgetting to mention it in my post)
That's the stage0 load of variable and streaming pack.

If you load at stage0 a single mono variable it will be ok.
But with the prim pack streaming of 4 variable it will not load.
That's because the pack do not use stage0 and is to late at stage 1 or 2 for the following code.

Using the once pack of MV fix it.
But also using a selector, we could make the code redo the stage 0 and load from the pack later.

[Spogg]

Whenever the schematic gets recompiled you will get a click if the audio stream is running! That goes for poly white and mono blue. As I’m sure you’re aware, if there’s no audio there’s no click. I never collated the nature of the click with schematic size, but it makes sense that a larger schematic would likely have a longer stream disturbance.
The best approach is to never put a selector in a situation where the user might want to change a stream path while the synth is generating sound. If you have that situation it’s best to use soft-switching using stream multipliers with the green switch control connected via a de-zipper. The downside of that is you won’t disable CPU usage of course.

Packing selector:
Your own comments reminded me of something I came across years ago. If an ASM code block has stage(0) processing a stream input, it may not read the stream input during the first sample period. My solution was to use a 1 sample delay on the input. I did this in the attached schematic and all 3 packers can be read via the input selector. I think my changing xmm0 to xmm1 meant that when stage(2) was reached the xmm1 register updated at the next sample, whereas xmm0 hadn’t seen the input. This leads me to believe that ASM code is executed before DSP code.

[Tepeix]

I was also sure that the selector would automatically make interruption in the sound due to recompilation.
But i'm not so sure now.

Here's a little synth.
Not so much process for now.. But a little more than my first test in blue.

Every selector that act on poly or blue are zipped in a special way.
(even osc are, but they do not so much audible crack when selected)

When one is selected the volume is swell with a zip.
When it's deselected the volume swell back to 0 then the selector cut the process.

I hear no click at all changing any selector when playing sound !)

(Maybe a test with even more process is needed, it's possible that the recompile occur but could do it's job between 2 sample)

(Note also that for the delay in blue there's a special need to make a fx loop which make think more complex..
The delay need to get his input zipped and not only his output...
but in white i do not make a fx loop, due to the short delay it's not so much a problem i think)

The zipped selector cut the cpu. But there's a zip for each process that need to stay one every time.

Hum for asm before dsp, i'm thinking of how to test it.
Note that your delay do a strange job. It get the value once selected, but that's the value of the last selected input and not the present one.

[Spogg]

That’s a very interesting demo!

It seems like I’ve been living under a misapprehension for many years. I would have predicted a click but your schematic suggests that only part of the schematic gets re-compiled, namely the stream path to the left of the selector. That would mean you would get an “interruption” but it wouldn’t be heard, because the whole schematic is NOT re-compiled.

This is good science, because my long-held “belief” has been demonstrated to be false. I’m not sure of the definitive explanation of what gets re-compiled and under what circumstances, but you’ve proved a point perfectly.

[tulamide]

I would have predicted a click but your schematic suggests that only part of the schematic gets re-compiled, namely the stream path to the left of the selector. That would mean you would get an “interruption” but it wouldn’t be heard, because the whole schematic is NOT re-compiled.

It get the value once selected, but that's the value of the last selected input and not the present one.

I didn't look at the schematic, but just by reading these quotes it tells me, that there indeed is no re-compile going on, which results in the values not being updated. How that is of use, may be considered by each individually. I don't see any.

[Tepeix]

I was surprise too !)
I think that there's a lot a things that tend to make think that all the code recompile.
Believed too from a long time.
For some code it's hard to imagine how the transition will do a click.
I'm not even sure why a filter would click, but i think they are.
Maybe some filter will click less needing some time to attenuate ?
Or maybe they all have an abrupt change ?
The osc doesn't seams to click even with no zip selector, i don't understand clearly why..
Also the stage0 make strongly thing about a recompilation.
It could maybe click even with a zip, if an index of circular memory is set there or something else.

Finally the most misleading thing is maybe with delay.
Now i'm not even sure that my example is absolutely click-less.
But it maybe attenuate the click enough to make it almost inaudible.
Normally all delay must also have their input swell progressively to not memorize an abrupt change.
And most code even if it's not explicit use some kind of delay, memory..

I maybe try long time ago the zip trick, not swelling the input of the code and hearing click, when not using a pure delay, it's hard to thing about the input swell.
This time trying with a delay i get the chance to think about the input, but i almost again miss this point

Maybe the click is also related with some memory.
Is it really audible if we have a sudden abrupt change in the signal ?
Maybe not if they are no repetition at all of this abrupt change ?
It's maybe like an impulse, containing all the frequency but only for a very
short time, with no repetition or memory process it's heard more like a noise.
And more noise when they are more random abrupt change.
But if they go into repetition it become like some frequency that reach high volume in a very short time...
All of this is Paradoxal, leading some confusion..

(Not so long ago i was also misleading with my output amp system in a very very crazy way..
Using an old Pioneer Sa-570 from 1986, never repaired, making lot of noise when changing volume and losing sometime stereo, i really loved the sound in any situation..
But it was making me thing that a modulated delay with no interpolation could sound very good !)
Hum maybe there's some mysterious process in some amp that could make sound good even very bad thing..

Most time i work on dsp most i thing it's important to have all kind of different measurement, as we rarely see clearly the signal in real time but a later scope of it. When delay come everything could become paradoxal, just like a true travel in time could be !!)
A sound could kill itself before it come to life, or maybe it need to go in the future, do something with another sound to create a son, that go to the past create is own father... in infinite loop... ...
... Then maybe the nature of all virtual life is the result of a virtual karma that try to justify itself with a cause, going back into to past to create something that make the illusion of causality ??
When in fact there's no cause or bad initial karma but just a virtual chaos that create life ???
Well i go very too far ! But dsp as some paradox that remind travel in time !
I thing about a scope that could record only the initial part of a process or maybe a particular fixed time..)

So i will try to upgrade to an fx loop and clean a little the mess, and maybe it's possible to have the zip also inside a selector to avoid its cpu cost..

I was doing this to solve another topic..
I wanted a delay that keep the same maximum time in any sample rate, but reinitialize the memory size to not use too much. (even if it's not a big amount of memory in most situation)
But the memories is not reset using selector in this way..