DSP Robotics Support

I somewhat understand what arrays are, it separates multiple entries with commas which are combined and split procedurally.

But how can i convert a float array to multiple float entries so i can send them individually to different modules?

Is there some kind of array extract that works like BUS extract?

You have two choices. The 'Array Get' primitive will let you extract any one of the values by giving it the integer index of the element that you want (note that, as in most computer arrays, the first element is at index zero not index one!). Or you can use the 'Array Splitter' primitive, which gives you a separate output for every one of the elements (extra outputs get added automatically when you create output links.)

It's very practical to rely on the text primitive. You can use sort for float as well to create ascending descending. The one thing I notice is that design wise the only array feature which can bug is the get command. Furthermore, there does seem to be issues with schematics which use other methods to "draw" and retrieve the array.

For instance, it may be best to send whichever item to the first or last (using float array) and merely change it to first or last and call it using set and various triggers. After it is called (trigger delay..), make sure you use a sample and hold and send it back. It's a way of avoiding the bug altogether.

Matth23u wrote:I somewhat understand what arrays are, it separates multiple entries with commas which are combined and split procedurally.

But how can i convert a float array to multiple float entries so i can send them individually to different modules?

Is there some kind of array extract that works like BUS extract?

An array is a list of cells. The list is indexed from top (index: 0) to bottom (index: number_of_cells-1). Each cell contains a value (in our example floats). You access the value by telling Flowstone to look at the array at a position specified by index. The array splitter is not such a good choice, because it is limited to arrays with a maximum of 50 cells. You can use it on Arrays with more cells, but only the first 50 will be returned.

Here's a screenie that may make it more obvious.



The post above mine about using the text box is actually not a good advice. The array has to be converted to text and later back to float, in order to use the text box. This adds to the cpu load. And you gain nothing from it other than seeing the values directly, which isn't needed, as it is not Schroedingers cat. A value added to an array stays the same value, wether you look at it or not.

I don't know how much you're into Ruby, but if the "one at a time" method via green is not enough and you need more versatile access to arrays, Ruby is the way to go.

Very convenient methods allow you to do pretty much everything you can imagine for an array. It comes at a price of course (comfort always needs more CPU), but it is well worth it, especially when dealing with large arrays.

tulamide wrote:I don't know how much you're into Ruby, but if the "one at a time" method via green is not enough and you need more versatile access to arrays, Ruby is the way to go.

Very convenient methods allow you to do pretty much everything you can imagine for an array. It comes at a price of course (comfort always needs more CPU), but it is well worth it, especially when dealing with large arrays.

I agree, but the one thing to keep in mind is that if you are intending to mix content from arrays into a combination of both ruby and primitives, there might be a time lag issue. Most recently, I tried this with a special drop-down menu system which automatically added nesting.

Though it seemed to work right away, I realized the latency was a big problem. If You make something like a dropdown list (relying on arrays heavily), then make it entirely with ruby. Mixing content can be really frustrating.

tulamide wrote:The array splitter is not such a good choice, because it is limited to arrays with a maximum of 50 cells

Thanks, that's a useful one to know - I had no idea there was an upper limit.

wlangfor@uoguelph.ca wrote:Mixing content can be really frustrating.

Yes, just like the String conversions which tulamide mentioned, there's also a cost for converting between 'green' and Ruby arrays. Although they work very similarly in practice, they represent the data very differently under the hood, so a fair bit of data juggling and copying can be involved. A handful of conversions here and there won't kill a schematic, but it's best to avoid going backwards and forwards too often. Thankfully, Ruby's versatility means that you rarely have to.

tulamide wrote:as it is not Schroedingers cat

However, I have sometimes seen incomprehensibly scruffy schematics with linking that seems to be inspired by String Theory!

trogluddite wrote:I have sometimes seen incomprehensibly scruffy schematics with linking that seems to be inspired by String Theory!

My early schematics were a real mess. I hadn’t grasped the use and usefulness of wireless links. I still like to show the audio routing with “wires” though.
I once saw someone’s schematic which only had modules with no wiring visible at all (at the top level) and I thought that was going too far.

Maybe it would be useful for newcomers to have some sort of tutorial they could be referred to…?

Cheers

Spogg

Spogg wrote:Maybe it would be useful for newcomers to have some sort of tutorial they could be referred to…?

Yes, there used to be some good ones on the old SM forum/wiki, but sadly, those are long gone, and have never been replaced (never mind updated to include Ruby etc.) I do think that it can be a tricky thing to learn from isolated schematics, however well put together they are, as building-in clarity and neatness during the design process is so much more effective than trying to refactor an existing schematic - fiddling around until something works is part of everyone's design process, but constructing a whole schematic that way is a recipe for chaos.

One of the big problems now that we don't have a Wiki is that good tutorials get buried away in forum threads where they're not easy to find - something hosted on your FlowStoners site might be a good solution, maybe?

For now, my top tip is: name everything! - never rely on memory as a guide to how a schematic works, label every module, every input, every output; and the 'comment' module is your best friend! I shall ponder this further while I go out to burn myself in the bank-holiday sun!

In general there is always a tradeoff to be made. Wiring can be very confusing, esp. if the wires are crossed. Wireless on the other hand can be a nightmare to trace back.

The same is true for green, red, blue and white. Green is event based, which makes it very comfortable to use as a reaction to user input. It fails however at all things timing based. Red has its own timing (ppq), is therefore more reliable, but can only be used for midi. Blue is direct, fast and reliable, but in itself only usable for mono synths. White is extremely versatile, takes away the pain of poly-signals, has a mixture of timing- and event-based, but can't be used for direct user interaction, midi and is worthless without converting to blue at same point.

Ruby is versatile, comfortable, event- and timebased (with audio routing it even is sample precise), can be used for user interaction as well as mono and poly manipulation, but is a script language and as such interpreted, which makes it so much slower than blue or white, that it won't be used very often for audio tasks (if at all).

There is no definitive answer, as to what you should use when. It is always dependend on the situation. But whenever user input is involved, timing isn't a concern and so you get away with green and Ruby.

Using scheduling (not necessarily the schedule method) to place events ahead of time, you can even do solid, stable sequencers with Ruby, because sync'ed to audio rate, the scheduled events happen exactly at the sample you wished for.

In cases like the above you won't hesitate for a second to use Ruby over blue, but in other cases you will prefer blue over Ruby.

Ok, I think I made my point clear: Be open for all of the systems offered by Flowstone and pick the one with the best tradeoff.