how does FS behaves under imported projects?

[kortezzzz]

Im wondering how FS behaves when old projects\SM projects imported to it.
Does it use the most up to date primitives from the tool box to open it or it just
reads the old\SM primitives from the file?
i mean, lets say i'v imported a SM projects with some old de-zipers in it. will FS replace them
automaticlly with newer de-zippers, or i should replace them manually?
BTW, does old SM de-zippers realy create noises and clicks???
just saw a post about it on SM forum...

[tester]

All SM projects behave correctly. Just load into FS and save as FSM. Everything is updated automatically. Even if some primitives are not present in FS (but were in SM) - they seem to work. In my projects, I had no backward compatibility issues.

The problem starts when you try to load newest FSM into older iterations of FS (even 3.x). Depending on what primitives you used (and how many) - it may indicate errors.

Also - if you load OSM project in FS, and save under old extension (i.e. OSM) - re-saved file will rather not open in SM, despite the extension.

[kortezzzz]

Good to hear. Thanks tester!

[tester]

Good luck with your projects.

[RJHollins]

Everything is updated automatically

Are we absolutely certain of this ???

I thought the schematic file contained all the PRIMS it was made from

[tester]

Yes I'm sure. I moved some old primitives from SM to FS.

I have no clear answer on what you ask. Primitives seem to be "visual modules" + "definitions"; what changed over time were these definitions. For example, the old editbox handler (i.e. "text edit" prim as far I remember; can't check it right now) had less nodes in SM than now, so when you load old projects now - this prim has just more nodes. If definition was unchanged, then prim will load without any change, even if it isn't present in the current toolbox. Maybe some definitions are in the core compiler, while others can be stored inside primitives structure. Someone else would have to answer on that.

One thing worth to mention however is - way how triggers are handled. There was some upgrade on triggers vs boolean policy, and while your old schematic will load correctly - it may not work correctly. But this is a matter of your design, that worked in SM. I had few modules like that.

//edit:

Check the attachement. It's the same schematic, created in SM. But if you re-save it in FS, then you will be not able to load it in SM.

[KG_is_back]

You can check the stock parametric equalizer module. There is a primitive called "Timeinfo" which outputs samplerate, tempo and "is playing" boolean. All these 3 functions are now separate primitives. Although the primitive is "SUPERCEDED" it works correctly. It seems either .osm and .fsm files contain the code of all primitives they use (in case they get deleted in updated version of FS/SM), or the Synthmaker/Flowstone itself has a list of Superceded primitives and is able to internally replace them with updated versions or groups of other primitives.