Array problem in Ruby - am I missing something??

[TimC-uk]

I'm enjoying getting to know Flowstone and Ruby, but I am finding some frustrating problems (quite apart from Flowstone crashing regularly on my system !!)
My current one is that I want to create a copy of an array, then do other things with the copy while the original remains unchanged - sound simple enough! But I'm finding that coding for one array changes BOTH of them (see example attached. I've been exploring for hours with things like Array.new, ...clone, all kinds of thing, but still end up seeing BOTH arrays responding to coding which looks like it should only affect one! Please enlighten me!! (I think the example is clear on what I'm trying to do).

[MyCo]

It's a problem called "deep copy". Clone and Dup only create copies of the outer array. But since you use an array of arrays, the inner arrays stay the same (you can think of them as pointer).

The easiest way to make a deep copy in ruby, is to serialize an object, and then deserialize it. That's the code for your case:

Code: Select all

@temp=Marshal.load(Marshal.dump(@ntes))

[TimC-uk]

Many thanks, MyCo, that is the answer! NOW I'm wondering, how did you find out about Marshal? Is there a reference available somewhere where all the methods (is it a method? I'm stll getting used to Ruby terminology!) that Ruby in Flowstone recognises?

[trogluddite]

Is there a reference available somewhere where all the methods

Hi Tim, every single one is listed in the Core API docs, here. With the exception of Win32API, none of the 'Standard library' (Std.Lib) stuff is in FS, only the ones on the 'Core' page.

Probably best not to try reading it all at once though! I find it best consulted in small doses when you already know what class of object you have, and what you want to do with it - the sheer number or classes and methods available is mind-boggling, but a great many of them will be used very rarely.

[tor]

If I understand the possibilities of Ruby correct, it should be possible to make a complex graphical element like a button with mouse interactions and then have it made into an array of buttons within the same piece of code. Despite my understanding there is no examples or documentation I have been able find describing anything such. Does any one in here have a clue if it is possible and if so maybe could point me in the right direction?

I guess maybe it is something like that in the sequencerpart of the examplesynth. But without commenting I am lost in there.

[trogluddite]

Does any one in here have a clue if it is possible and if so maybe could point me in the right direction?

Yes, certainly possible, I use a technique a bit like that for the handles and lines in my GraphicsPath editor - though it's probably not a good learning example, as the methods are all a bit jumbled up!
There are essentially two ways you can do it...

1) Make a whole new class of object "MyButton", and create methods for it to define how a 'MyButton' object works. You could then create buttons using something like "@play_button = MyButton.new("play")", and make arrays of the new objects. But making new classes is a huge subject in its own right, and needs to be treated with extra-special care when using Ruby inside FS.

So, method two is probably simplest - and closer to the idea in your original question...

2) Define some methods that define how to do things for a single button - "drawMyButton", "toggleMyButton" etc. Then store data about the buttons inside an array - where they are on screen, current state etc. - easy in Ruby as you can put a mixture of any old objects into an Array, including other Arrays.
Then you need a few routines that scan the array and draw the buttons, or check for mouse clicks etc. for every button all in one go.
It does take quite a bit of setting up sometimes - but the big advantage is that you can change all of the buttons at once by just editing the "one button" chunks of code.

Here's a little example - an array of different sized round toggle buttons...

Button_Array.fsm

(1.53 KiB) Downloaded 1208 times

For folks coming new to Ruby from SM etc. there are probably a few strange concepts in there, so I'll cover a couple of points - not in much detail, but enough to know what to look for in online tutorials etc., or to ask about here.

Arrays - can mix all kinds of data together, and can include sub-arrays, sub-sub-arrays etc. No more SM restriction of all data having to be the same.
Hashes - a bit like an array, but instead of items being stored in numerical order by index, you give each one a unique 'key'. The keys and values can be just about any type of data that you like - but symbols (colon followed by a name, e.g ':key') are often used as they are quicker to look up than strings or numbers.
Enumerators - any of a whole range of methods that are used with "collections" of things like arrays. An enumerator automatically goes through all the items in the collection, doing something to each item in turn - no need to define loops, or clumsy index maths. The simlplest example is '.each' - which does just that, accesses 'each' item in turn.
Blocks - So what does something like ',each' actually do to each of the array items?
On it's own, '.each' doesn't do anything much at all, it just scans through the items - but, like many other Enumerators, you can tell it what to do by giving it a chunk of code to work with...

Code: Select all

myArray.each do |this_number|  # All of this part must be on one line
this_number = this_number + 1
end

Everything between 'do' and 'end' is fed into the '.each' and will happen for every item in the input array. As each item is pulled from the array, it gets assigned to the variable between the || characters '|this_number|' - you then just do whatever with 'this_number' , and that will be what happens to everything in the array. And not a single array index in sight!
You can also use curly brackets instead of 'do' and 'end', which is great for little 'one-liners', e.g....

Code: Select all

myArray.each{|this_number| this_number+=1}

...which does exactly the same as the previous example - adds one to every number in the array.

[tor]

Fantastico!!!

Seem like a great example. Now I have something to bury my head into for the night

Thanks a billion for taking the time to make this Trog!

[trogluddite]

No problem
I've built a load of test rigs and experiments like that while learning Ruby - I could probably pull out a few other useful examples if I just get around to tidying them up a bit and commenting them.
Ruby is just so damned BIG - I file away even the tiniest of scraps for future reference, because you couldn't possibly keep it all in your head at the same time.

[tor]

Great!

After some studying of your code, I found that just small changes had to be done to adapt it to my button.

Button_Array_v2.1.fsm

(2.67 KiB) Downloaded 1130 times

Yet I have trouble understanding why not the 'def init' part at the beginning of the code does nor refresh when I ie change the @px value (X offset) in properties. When I change the value it only moves the whole array in one direction instead of also adjusting the spacing of the buttons.

Next challenge is to get the buttons mapped in the y direction (rows) aswell.

I am starting to like Ruby

[trogluddite]

Yet I have trouble understanding why not the 'def init' part at the beginning of the code does nor refresh

Ah, that's because my original didn't have any external options.

At the moment every single part of the code is inside a "def....end" method definition. When FS does a 'default' run through the code, these get parsed to make the definitions, but none of the code inside them actually runs.
To make something happen at an input change, you have one of two options...

1) Simple but limited.
If you have some code that isn't 'wrapped up' into a method, then that code will run whenever an input changes - so you could "unwrap" the init code so that it's just 'bare code' and it will run when an input changes.

2) More control.
Alternatively, put an 'event' method into the code. When there is an event method, that will get called when an input changes, instead of all of the code being parsed. Inside the 'event' method, you can then put "init", to call the init routine whenever you want. That gives you the power to be able to test which input changed, so that you call 'init' only when you really need to. FS will still automatically call 'init' at startup too.

Note that this is a choice between one or other of those two techniques - adding an 'event' method will over-ride (1).