SynthMaker 2.0.1 released

MichaelBenjamin · 20 Jan 2011

nice, but some more explanation is needed. is stage 1 now obsolete or what is it that stage 2 is now the "normal" processing? is stage 1 then a -1 delayed version of this?

Andrew J · 21 Jan 2011

MichaelBenjamin wrote: nice, but some more explanation is needed. is stage 1 now obsolete or what is it that stage 2 is now the "normal" processing? is stage 1 then a -1 delayed version of this?

It's explained in the manual.

__________________________________________________

Stages

The code is split into four parts called stages. These are numbered 0,1,2 and 3.

Stage(0)

Stage(0) runs only for the first sample and is intended for processing that you only want to happen at the very start, usually to set up other parameters that you will then use on every sample.

For the example we’ve just been looking at we could put the array initialisation into Stage(0) and it will run only once.

Defining the stage is very easy:

stage(0) { < code in here is executed only for the first sample > }

Stage(2)

We'll jump to Stage(2) now because this is the default stage. Any code written outside of a Stage definition is assumed to be Stage(2).

Stage(2) code is executed for every sample (including the first) and happens after Stage(0).

Stage(1) and Stage(3)

These two stages are only used for implementing delays. They are needed to make sure that data flows correctly when one or more delays are chained together in a feedback loop.

The software executes the code in stage order so after Stage(0) Stage(1) goes next.

Stage(1) should be used to move data from internal variables (most likely a buffer) to the outputs. This ensures that all components have a consistent output value before doing any calculations.

Next the standard Stage(2) is executed. Any code that needs the outputs of any delays will have the values they need now.

Finally Stage(3) is executed. This should be used to move data from the inputs to internal variables (again most likely a buffer) and perform any calculations.

Note that each stage is executed for the whole of the schematic before proceeding to the next stage.

An example of how to use Stage(1 ) and Stage(3) for a delay is shown below.

streamin in; streamout out; streamin delay; float mem[44100]; float index; stage(1) { out = mem[index]; } stage(3) { mem[index] = in; index = index + 1; index = (index<delay)&index; }

Note that because the transfer to outputs in Stage(1) occurs before the buffer update in Stage(3) this will always produce a minimum of 1 sample delay. If you need a delay that will work correctly when the input delay length is zero samples then you can implement this by modifying the above code as follows:

stage(1) { out = mem[index]&(delay>0) + in&(delay==0); }

tor · 21 Jan 2011

@Andrew J

Hi Im trying to wrap my head around this... can you or any one help me out here:

streamin in; streamout out; streamin delay; float mem[44100]; float index; // So far, so good. Go to stage 3: stage(1) { out = mem[index]; // Now I get lost.... if index is equal in both stages how can it be a delay. How does this work } stage(3) { mem[index] = in; // input written to current mem index index = index + 1; // index increase index = (index<delay)&index; // index=index if index<delay or index=0 (count reset when index reach max) Still OK }

infuzion · 21 Jan 2011

Stages: So do we have to re-code our hand-coded delays then?

WaveDraw speedup: Yes, it does dramatically fix the problem I was having!! 😇

stw · 21 Jan 2011

tor wrote: @Andrew J

Hi Im trying to wrap my head around this... can you or any one help me out here:

stage(1) { out = mem[index]; // Now I get lost.... if index is equal in both stages how can it be a delay. How does this work } stage(3) { mem[index] = in; // input written to current mem index }

Simply because of the order of processing. Since the input read is defined at a later stage as the output write the out will happen one sample later than the in. I hope i'm right here...

tor · 21 Jan 2011

nah.. it is more than one sample...

i undertand that stage 3 is a looped array.. but i do not get how the index in stage 1 relate to the delay value

MichaelBenjamin · 21 Jan 2011

thanks for the information andrew, i didnt think that the manual explains this.

afaik stage 3 is just like stage 2 and 1 but occurs after the sample for stage 2 has been calculated. to be honest i dont really get that stage system (besides stage0), since sample delays and order of processing could aswell be done in plain sm pseudo code. but maybe all my stageless code is then one sample behind or too early, and i never heard it.

tor · 21 Jan 2011

Aha... now i get it. Because of the one sample delay the output dont get the input value untill next cycle.

STW.. thanks for the push 🙂

tor · 21 Jan 2011

MichaelBenjamin wrote: thanks for the information andrew, i didnt think that the manual explains this.

afaik stage 3 is just like stage 2 and 1 but occurs after the sample for stage 2 has been calculated. to be honest i dont really get that stage system (besides stage0), since sample delays and order of processing could aswell be done in plain sm pseudo code. but maybe all my stageless code is then one sample behind or too early, and i never heard it.

Yes what is the difference of:

out=a; //stage 2 a=in; //stage 2

and

stage(1) { out=a } stage(3) { a=in }

tor · 21 Jan 2011

Seems to me that code work any ways.

trogluddite · 21 Jan 2011

MichaelBenjamin wrote: order of processing could aswell be done in plain sm pseudo code

Within each code block, yes, you have complete control over execution order. But if you have multiple code blocks in a schematic with lots of 'spaghetti' joining them together, it's much harder to control the order in which each of those modules gets executed (sometimes you can play with the link order forever and still not find the right way) This is especially true if there is feedback involved - the feedback input should always be the result of all the outputs on the previous sample. Using stages can ensure that the feedback input value is read before there is a possibilitiy of the value being modified by code which is running the current sample iteration.

The new 'fix' is still going to require some manual editing for anybody that had good reason for using stage 1 - the stage 1 markers will all get 'converted' to stage 2, and will need changing back if stage 1 really was the intention. The 'recompile on load' behaviour is a good idea I think, but hand-coded stages are often there for a reason. Makes me shudder a bit having my source code messed with in a way which I can't control.

I suppose that as long as the new 'stage2=default" leads to more stable schematics we'll just have to accept some inconvenience on the understanding that it brings advantages in the long-term.

ccpurno · 21 Jan 2011

Thnx Synthmaker team!! I will buy the upgrade now!

CC

Andrew J · 22 Jan 2011

Nice to see everything sorted out while I was away at the cricket (watching the great Aussie escape). Good explanation Trog.

DaveClark · 23 Jan 2011

Hi all,

I just installed 2.01 on a 64-bit Windows 7, in parallel with a 2.0.

I created some explicit stage1 Code and ASM, saved in 2.0, then imported into 2.01. I see, using text boxes, that the default code is indeed changed to stage2, but the explicitly stage1 stuff is unchanged. This is contrary to what I read in the release post.

Has anyone else tested the behavior? I am very concerned if only the default behavior is changed, contrary to what I understood should be happening.

Thanks for any info.

Regards, Dave Clark

MichaelBenjamin · 23 Jan 2011

dont know what you mean with default, but i would guess its possible that asm doesnt get auto-converted, only plain sm code.

stw · 23 Jan 2011

DaveClark wrote: Hi all,

I just installed 2.01 on a 64-bit Windows 7, in parallel with a 2.0.

I created some explicit stage1 Code and ASM, saved in 2.0, then imported into 2.01. I see, using text boxes, that the default code is indeed changed to stage2, but the explicitly stage1 stuff is unchanged. This is contrary to what I read in the release post.

Has anyone else tested the behavior? I am very concerned if only the default behavior is changed, contrary to what I understood should be happening.

Thanks for any info.

Regards, Dave Clark

I guess it only converts pre V2 code because the change was introduced in V2.0.

DaveClark · 23 Jan 2011

Hi MichaelBenjamin and stw,

Thanks to both of you for your posts, but it appears that you are misunderstanding what I did and/or the release notes.

Michael:

From my post:

"I created some explicit stage1 **Code and ASM**, saved in 2.0, then imported into 2.01." (Emphasis added.)

On Edit: However, I hope to have time today to double-check my results to ensure that I saw what I thought I saw --- i.e. the same results for both. Later edit: Please see update below.

stw:

From the release notes for 2.0.1 (2.01):

"This update now does this automatically on loading files created in 2.0 or earlier. "

As I said in my post, the test clearly shows a difference between 2.0 and 2.0.1, confirming that the change occurred at 2.0.1, not 2.0. (On Edit: I may be mistaken about when this change was made.) As I said, the text boxes attached to the output show:

A) Certain code that runs by default as stage1 in 2.0 runs at stage2 in 2.0.1 and (On Edit: Although Malc confirmed this statement, I now think that I was mistaken and was not looking at the default staging. If stw is correct, then this problem is even worse than I had thought.)

B) Code explicitly run at stage1 in 2.0 continues to run at stage1 in 2.0.1. (On Edit: Still true and bad news.)

This is not only inconsistent, but contrary to the release notes as I understood them. I tested this only on 64-bit Windows 7 so far, and I don't particularly want to test it on any other machine as long as there is any possiblity of inconsistency.

Regards, Dave Clark

infuzion · 23 Jan 2011

DaveClark wrote: B) Code explicitly run at stage1 in 2.0 continues to run at stage1 in 2.0.1.

This is not only inconsistent, but contrary to the release notes as I understood them. I tested this only on 64-bit Windows 7 so far, and I don't particularly want to test it on any other machine as long as there is any possiblity of inconsistency

Welcome to SM-land Dave! Yes, B) can be an issue... might need to email support@synthmaker with example OSMs. It is not unusual that SM releases do not work as planned.

DaveClark · 24 Jan 2011

Hi infuzion,

Thanks for the Welcome. Wheeeeee!!

Best regards, Dave

------------------------- PS: While I'm here, and for anyone interested, I did double-check the results, and again what I see is that neither Code nor ASM are migrated, AND I held my breath and checked Vista-32: Same behavior as reported for 64-bit Windows 7.

DaveClark · 24 Jan 2011

Hi all,

Update on staging changes:

I've updated my post of results regarding staging behavior, but it's probably confusing because I'm now confused myself.

Although Malc confirmed to me privately that point A) in the previous post is "the intended behavior," in looking again at the default behavior, it appears as though the staging change was made, as stw claimed, at 2.0. I don't see any documentation about this in the Release Notes, and in fact they lead me to conclude that it occurred in 2.0.1. Did I miss something? Again, I now believe that stw is correct and that I was looking at the explicit cases while thinking they were the default.

Regardless of when it occurred, this change is potentially a disaster. To fix one group of users' synch problems, other folks' synch problems may have just gotten a lot worse --- that is without the migration tool working properly and for both Code and asm components.

Problems may occur if you have used stage0 and stage1 in some asm components but not in others, and if the timing of execution is important to proper functioning.

Malc also confirmed that the migration tool does not work for asm components but also said that he may change this. Again, I still don't think it works for either Code or asm components for 2.0 -> 2.0.1.

*Update: Just heard again from Malc. He explained all that I'm seeing, and he provided a list of action items he intends to accomplish to update 2.0.1 to address additional issues with this staging change. Many thanks to Malc for a quick response, as well as outstanding support in the past.

Regards, Dave Clark

stw · 25 Jan 2011

One important note: After fiddleing a bit with the stage order and constantly increasing confusion about what SM is doing or not i found out that SM2.01 only converts stages which are exactly named "stage(x)"! and nothing else. I had some code with a space between stage and the breakets like "stage (x)" which wasn't converted at all. So take care of this or better - Malc change the parser for that.

Tom7777 · 25 Jan 2011

Was anything done in V2 for toolbox organization like being able to use sub folders etc?

Seems V2 made things worse when it was first released -

Messy vs. Tidy

Hopefully this will be done but i haven't seen anything listed yet so i probably won't be updating just yet.

infuzion · 25 Jan 2011

Tom7777 wrote: Was anything done in V2 for toolbox organization like being able to use sub folders etc?

No sub-folders. The folders you had placed your modules in from v1.x are automatically re-created though.

Mo · 17 Feb 2011

The stage in the delay from my toolbox is now stage2 and stage3. But following the manual example, it's stage1 and stage3. Should i change the stage2 back to stage1? Maybe stages are not necessary at all like MyCo's optimized delay.? Will have to test it, but maybe someone knows already..