Ruby String Array

[billv]

I found the bug in the preset system I installed in my synth.
String array prim's were not updating...
For arrays like the matrix and tempo modules(no comma's),
its not a problem as i can route output array back in the input array.
But the rest of the synth needed a solution.

So i built a "Ruby string array" that could handle feeding back a de-limited array..
End result seems to work perfectly ....but why this behaviour...???
Is it a bug...

array_2.08.fsm

(113.02 KiB) Downloaded 933 times

EDIT: Fsm re-uploaded with trog fix...and properties adjustment(filename+folder)

ScreenShot288.png (41.3 KiB) Viewed 17416 times

[tester]

Nope, it works rather correct. At least without looking into schematic I would say that, because I had today similar issue in greens. My guess is here this. Additional empty line at the end of array (it exists because empty line is also a beginning of modules like "text") is used by string processing as "line with null content" while in int/float processing - because it is a last line - it is not feed by zero and it is ignored. I guess that ruby and greens see this thing just differently.

[trogluddite]

It's this little section here that's causing the problem...

Code: Select all

if i == 6 then
a = Array.new[0..9]
  splitAt = /\n/
  a = @txt.split(splitAt)[0..9]
output 0,a
end

There are different standards for indicating the end of a line. Sometimes it is just "\n" (new-line), sometimes just "\r" (carriage return") - but the standard in Windows is to use both; "\r\n", and this is what the output from string prim's uses.
So, when you split at the "\n", it is leaving the "\r" at the end of each string.

But now it gets really weird.
When displaying its GUI the string primitive only looks out for "\r" and ignores "\n" - so in this case the extra "\r" is treated as extra new line. OTOH, the 'text display' module (using MGUI) only treats "\n" as a new line and ignores "\r", so no 'extra line'
Here's a little schematic that shows the problem...

Line termination.fsm

(2.38 KiB) Downloaded 927 times

So we have "\r\n" at prim' outputs (and the Windows standard), "\r" for string 'property' display, and '\n' for "MGUI" string display
Bug ? - hmmm, I'm not sure, but it would be damned weird to design it so inconsistently on purpose!!

Luckily, the 'split' method in Ruby has a special notation for splitting lines, regardless of what termination is used - just call it with no arguments...

Code: Select all

if i == 6 then
a = Array.new[0..9]
  a = @txt.split()[0..9]   # Empty arguments for split
output 0,a
end

[billv]

Note:
I re-uploaded original fsm to prevent possible conflict.....
I was using X11data folder and file in test modules...

It's this little section here that's causing the problem...

Thanks Trog for explaining this and the fsm.
Fix works great.
Dream come true.....a string array that does what i need it to do...

Note:
What about the whole code in general Trog....?
See any potential errors in there..??

Do we need a 'guru' version instead...???

I've spotted a possible issue when the array is full [999] items, or very large...
I pre-loaded an array and got some slow behavior in the circuit...still testing..

[trogluddite]

What about the whole code in general Trog....?

Well, there's a few things I might do differently, but first there's maybe something else to look into...

The problem that you started out with - the array not updating - could have a simpler solution. I'm not totally sure without looking at the original, but there's a known problem when feeding string arrays from file/preset data.
Very often, the cure is just to insert a string primitive just before the 'set array' input of the sting array primitive - very often that seems to 'rebuild' the string formatting so that it gets read correctly.
Now that I think of it, maybe this odd "inconsistent line terminator" thing is what causes that problem?

As for the code - here's a few tips...

One object - Many references
What do I mean by that?
Well, when you do something like...

Code: Select all

a = @b

...the variable 'a' won't contain a new array with a copy of the array '@b' data. Variables in Ruby in fact don't contain very much at all - just a reference to an 'object'. This little demo will explain better than words can...

Same Object.fsm

(412 Bytes) Downloaded 904 times

For this reason, your code has many duplicate references - @b, output 0, and 'a' are often just acting like "Windows shortcuts" to exactly the same array.

There's nothing especially "wrong" about that, it's just how Ruby works (and saves a lot of memory!). But, it can lead to a lot of accidental bugs - you try to change a single array entry, or edit a string, and all of a sudden, a load of other variables change that you didn't expect!

The trick is to know that there are two kinds of Ruby method...
The first kind is most common, you call a method, and the method gives you back a nice, shiny new object - no problem there because that breaks the link with the old object - no duplicate references.
The second kind of method takes an object, does something to it, and gives you back the same object - changing a single element of an array is probably the single most common example of this. It would be wasteful to make a whole new array just because you wanted to change one element, but it means that all other reference to that array also see the same change.
Just to be confusing, this second kind goes by several different names! - but when you're looking at the Ruby documents, look out for phrases like "modifies the receiver", "returns self". It's often indicated by a '!' ("bang") at the end of a method name - but usually that's only if there's a "non-bang" version with the same name.

So how does knowing this help simplify your code?
Well, firstly there are quite a few places where you are "copying" the array, but Ruby isn't really making a copy - now that we know that there is only really one array, we don't need those at all.
Also, because variables are just "references" to objects, we can lose many "Array.new" lines - Ruby only cares about the object's "ID code", and doesn't care what kind of object it is, so there's no need to tell it in advance what you're going to use a variable for - it's not like 'green' where the Integer/Float etc. data types are set in stone and you must set connector types accordingly.
But the biggest cleanup is that we can now get by with far fewer variables - the less the better, to make it clear in the code that there's only one array.

But there's a problem...
Ruby doesn't have "types" of Array - they can contain a mix of any old kind of objects. So what happens if we make the array bigger, so that there are empty 'slots' with no string in them? Or accidentally put a number in there instead if a string?

...Oh, wait, no there isn't!
Malc thought of that one - just like the "auto translate" between green numbers/strings etc., when you send the array to the output, it gets auto-converted into a valid string array. Numbers get converted into their string equivalent, and empty slots are filled with empty strings.
The 'auto-translate' isn't totally infallible, because many types of Ruby object don't convert to 'green' types in an obvious way - but Malc seems to have done a pretty good job of handling it to minimise any errors.

...OK, maybe a little problem...
You said that for large arrays, things were going a little slowly. Well that isn't totally surprising - a string array primitive will be made from super-fast compiled C++ code, and there's just no way that Ruby can compete with that. Also, imagine what that "auto-translate" routine must be doing - every time the output changes, it has to check every single entry in the Array to see if it is a valid string, and then deal with anything that needs replacing.

Lean Green Machine
That's why I suggested to check whether the problem was due to the old SM string array problem - because this is one of those cases where Ruby doesn't have any advantages over 'green'. Unless there are some new array functions that you really need to add, or there really is no other way around your bug, the primitive is always going to be a much better performer.
(tester will be pleased! )

But just for completeness, I'll knock up a "Ruby String Array", so that you can contrast and compare with your version - to follow shortly...

[trogluddite]

Here we go - I've added the "parse from string" feature, but other than that I've tried to replicate the primitive exactly.

String Array in Ruby.fsm

(2.33 KiB) Downloaded 985 times

[billv]

That's why I suggested to check whether the problem was due to the old SM string array proble

The problem is the way I've put every preset value into a slot(comma's).
The FS String array does not deliver here...
If I input strings like 'A'....'B cannot be routed back into 'C' so the array updates...

ScreenShot290.png (17.49 KiB) Viewed 17371 times

your code has many duplicate references

thanks for the tips and fsm's Trog...going through it...

[trogluddite]

Ah yes - see what you mean now, can't change the default delimiters - I always miss the obvious stuff!

You can do it using the "String to string array" and "New Line" primitives - I think even with that extra stage, it would be faster than the Ruby, certainly for all the other more commonly used inputs.

To Array.jpg (29.76 KiB) Viewed 17368 times

[billv]

You can do it using the "String to string array" and "New Line" primitives

Awesome...