new prim idea: code/ASM component with text input

[KG_is_back]

While working on the smart-delay-code-generators I had an idea for a very cool prim. How about adding a text input to code and ASM component to input code directly from schematic green. The way I imagine it to work is, that Code/ASM component would have an input for text, through which you could paste code into it via green text connector from the schematic. Every time you do that, it would cause the schematic to recompile, similar to when you edit code manually or use selectors.

Current alternative to this is, to have many versions of the same code/ASM component and use selector to switch between them. However, with above-mentioned feature it would be possible to simplify many situations. You could use code-generators like this one for efficient delays directly without need of manually copy-pasting (which is also not possible once schematic is made into app or VST).

I already have many ideas, where this could be very beneficial. For example FIR filters - change in the impulse length would change the lengths of internal buffers and loops.

I believe it would not be a hard feature to add, and would widen possibilities of code/ASM considerably and simplify many schematics, where many selectors or bus connections are needed to switch between variants of multi-output code component.

[MyCo]

Thought about that quite often before. It surely would have some applications, but would make FS very unstable if you mess up. Another disadvantage is that you would have to retrigger the compilation process by green (like the selector), so you can't smoothly switch between one code and another.

[KG_is_back]

Yes, I aware of that an it's not the point of this new prim to solve those issues. It certainly is an advanced feature.

What I mean, unlike Exo, I'm a realist. With flowpaw around I don't expect a mayor revision to the Code and ASM components to happen anytime soon. Having an ASM component that can receive code via text would allow us to write "custom code components" in ruby. It would led us boil down features of ASM that are not present in the current Code component into the "custom" one. For example IF/ELSE branching and variable-length-LOOPs are not present in code component, because its code is expected to be poly and mono4 compatible, but mono streams would greatly benefit from them.

Also I expect it to be a GUI less prim, separate from current code and ASM components. Adding new input to those would result in incompatibility with older schematics (input connectors order would get messed up).

[Exo]

Yes I have thought about this also, would definitely be a cool feature. No reason why it is not possible or fairly simple to add as a separate GUI less component.

I also would like to see the same thing for Ruby, then it would be possible to Write Ruby code in an exe or dll while it is running from the GUI.

In fact the old experimental version of Synthmaker SMX had support for Lua which worked like you suggest. You connected a text component containing your Lua code and then triggered a recompile.

[Tronic]

I also would like to see the same thing for Ruby, then it would be possible to Write Ruby code in an exe or dll while it is running from the GUI.

you can use the method eval("your ruby code text")

my point of view is to add more featured to DLL component, so you can write code directly in C, i have already made some experiment with, that act as a Assembler executor but the performance is strange, because you have to trig it with the primitive Frame Sync. Why not implement an possible solution to take in the dll every function for VST SDK, and the main thread loop GUI and Process?

[Exo]

I also would like to see the same thing for Ruby, then it would be possible to Write Ruby code in an exe or dll while it is running from the GUI.

you can use the method eval("your ruby code text")

my point of view is to add more featured to DLL component, so you can write code directly in C, i have already made some experiment with, that act as a Assembler executor but the performance is strange, because you have to trig it with the primitive Frame Sync. Why not implement an possible solution to take in the dll every function for VST SDK, and the main thread loop GUI and Process?

Ah I wasn't aware of eval, thanks.

Yes a proper Flowstone SDK would be ideal, then we could access the GUI and everything else. I guess they went with the DLL as it is because it is was probably much quicker and easier to implement. Alot of things are possible with it but it does have major limitations.

[KG_is_back]

I also would like to see the same thing for Ruby, then it would be possible to Write Ruby code in an exe or dll while it is running from the GUI.

you can use the method eval("your ruby code text")

Well, I didn't mentioned Ruby in this topic, because I suspected it has this feature, since it's interpreted language. The code of ruby is also basically just a text, that is being interpreted on fly. It's no surprise that you can run a text as a ruby code directly from inside ruby.