DSP Robotics Support

What I'm missing is something like this: green "expression" and green "expression matrix".

These primitives could work in similar way like "string" and "text".

I noticed, that string/text primitives connected to floats - send either triggers (if they contain text) or values (if they contain numbers), or they filter text ("1243gfgff" will end like "1243", but if starts with text, then output is zero).

"Expression" green primitives could be something like "strings", but designed for simple (or more complex equations). For example if you type an expression text "2/3" and connect to float - it would produce "0.666..." as a result. Or if you have text-like box with such equations, then it will produce an array of results.

Expression connected to string - sends text/string.
Expression connected to float - sends result of an equation.
* Multiple expressions connected to expression = sum of expressions & maybe some basic auto-simplifications (like a+a=2a?)?.

It would be great for fractional numbers and equations.
Plus - sometimes you connect too many links and modules in order to perform a simple operation.

A bit like this you mean ...


In fact, using 'eval' you can get a step closer than that even...

Trog - what for is ruby good if may I ask?
I noticed on various examples, that for streams - it rather lacks performance.
So it's rather static calculations and gui related?

Expression primitives should be so simple as possible. No ins/outs inside code, no strange things; there would only one default in and one default out, and all operations would be performed inside.

tester wrote:Trog - what for is ruby good if may I ask?
I noticed on various examples, that for streams - it rather lacks performance.

I think of it as 'turbocharged Green code' - the stream 'frames' are a nice little add-on that's useful maybe for analysis etc., but I don't think Ruby was every intended for real-time audio processing. It's there because, over the many years of SM, lots of people found the same thing with too much 'spaghetti' to wire simple formulas etc. And for conditional logic, it sure beats the hell out of trying to track down rogue trigger loops.

'What is it good for?'
Well that all depends on who is asking - for a user who's prime concern is better audio quality with lower CPU consumption, it offers very little besides, as you say, maybe a smarter GUI, or clever 'parameter juggling tricks' .
But, in the context of a more general programming tool, it has a lot to offer - the kind of data processing, hooks into the operating system, and mathematical accuracy that was far out of reach with SM. The better event timing alone makes it valuable to me - but I have programming interests besides making audio plugins, so a different mix of requirements.
I'd still like to see streams get a good makeover though! I've got a few half-done schematics stashed away that just couldn't quite be realised with the current audio system.

tester wrote:Trog - what for is ruby good if may I ask?

for things you were asking in the 1st post ruby should be the perfect thing, ruby is very powerful in working with strings, like - searching for digits inside a string - ... i also use it often to build small primitives out of ruby which would take 5 to 10 green primitives but with ruby just 2 or 3 lines of code.... and i don`t have to think about how i to connect which primitives - since ruby i often write just a line in ruby which takes a minute to get my result before i start to search primitives only because i`m too lazy to search the green and think about how to connect them ...

So, in other words - ruby would be also rather a good tool for graphics, like creating photoshop-like filters?

tester wrote:So, in other words - ruby would be also rather a good tool for graphics, like creating photoshop-like filters?

Well, powerful for vector and text stuff ATM - there was a post where the dev's said they would look into more powerful bitmap features, but I guess we'll have to wait and see about that.

To me the biggest power is a little more abstract than any particular application - Ruby just handles data/information so much better than anything we had before. For example. the data manipulation in something like mccy's SFZ file 'translator' would have been completely impossible before Ruby came to FS - there wasn't the power to dig inside files in that kind of way, or to treat big blocks of data as single "objects" and pass them around as easily as you can a single float number.
That's something that I decided to embrace, because I often feel that the drawback with most VSTs is rarely to do with the audio quality or flexibility - rather, it is the "laboratory equipment" feel of the user interfaces.
(even to the extent of simulating shadows that conceal the labels and fake "screen glare"! )
Hence throwing myself into FS - complex Ruby data processing plus hardware interfacing will allow me to explore alternative means of control so that I hope, one day, my VSTs will be as intuitive to manipulate as my guitars.

I am fortunate enough to have been programming for many years, though - I can understand why Ruby will seem daunting to many users without that experience - and the "language barrier" makes it hard even to explain the advantages sometimes.
So I will continue to post 'green' examples where possible when that is asked for - but I post also the Ruby examples, because I feel that they are sometimes genuinely more elegant, efficient or effective. As Nubeat says, that applies to a few of the problems that you have posted recently - to take a couple of examples...
- Generating random number with precise timing - when audio is running Ruby is locked to the sample clock, instead of the vague 'free-running' time derived from Windows timers. And the function that you built to get a good value spread could be stated in only a line or two of code much more closely resembling the written algebra.
- The 'multi-range' knob - The trigger system often obscures the true processing order in such situations, even when it is well understood (i don't believe that anyone ever understood it fully!). Sequential lines of code and method calls can make this kind of problem much easier to state succinctly, and there is a great deal of control over how different inputs and outputs send/receive triggers.

Nubeat7 wrote:i also use it often to build small primitives

Yes, I really like that way to look at it. There have been a few little modules posted already that have gone into my toolbox - the connectors on them are just like any other - whether or not they are Ruby inside doesn't matter so long as they do what they are supposed to. Once some of us get to know Ruby well, no doubt there will be many 'feature requests' that will be solved in code by forum users - leaving the dev's plenty of time to write us some really cool new stream processing primitives!

Some day I will give you my interface to rebuild in ruby if you wish A lot of principles and inter-relationships to follow. Who knows, maybe you right, maybe it will work better than my current design in terms of producing less triggers in terms of resulting glitches in crucial points.