DSP Robotics Support

Posted: **Fri Dec 11, 2020 9:03 am**

newdsp wrote:Very nice simulation. Can anybody improve it or modify it ? Does it include the fsm file ?

Yes the zip contains the FSM file.

Anything I share is free for anyone to do whatever they want with.

Posted: **Wed Dec 16, 2020 6:08 pm**

I opened the FSM file with Flowstone 3.0.9b2 and it didn't run. Then i removed the midi input and the asio output and placed them back again. As soon as i turned on the midi input it shows some ruby error in module. What version of FS do i need to use to not get any errors ?

Line 8 in "Allow GHB notes only" gives the error but it's caused by line 2.
Line 2 says @m = (4) but it's supposed to be @m = [4]

Even after fixing all the errors it's still not making any sound.
Any ideas ?
Should I use FS 3.0.6 to open it ?

Posted: **Thu Dec 17, 2020 8:06 am**

Unfortunately the two betas available for download on this site have many bugs and should be avoided at all costs. Many of us have chosen to use 3.06, including me. So the schematic will work in 3.06.

viewtopic.php?f=2&t=11635

Posted: **Thu Dec 17, 2020 12:19 pm**

I tried in 3.0.6 and it's giving the same errors. I only made it work with 3.0.9b2 (v3.0.9b2-3078-g4cd0529) but I had to remove the module called Open Note Control. All the Ruby script indentations are messed up in that module. It's not clear why. Here is what I got so far. Of course the presets that used that Open Note Control module are not working properly.

Posted: **Thu Dec 17, 2020 2:39 pm**

This is weird. I tried the version I uploaded in 3.06 and it still works fine for me.

Line 2 is where the array is declared, so @m = (4) is correct. The (4) in brackets declares the size of the array, not an element. It needs to have a size of 4 elements for the later midi messages.

The file you just shared is made in the beta with many bugs.
Maybe try re-downloading and opening with 3.06…

Posted: **Thu Dec 17, 2020 4:48 pm**

Spogg wrote:@m = (4) is correct. The (4) in brackets declares the size of the array, not an element

Nope! - @newdsp is closer to what you were aiming for. Your parentheses are just evaluated as enclosing a mathematical expression - so it just assigns integer four. To create an Array, you either need to do what @newdsp did, and use square brackets (albeit his array has only one element - you might prefer e.g. @m = [0, 0, 0, 0]), or use the Array.new method...

Code: Select all

@m = Array.new        # Creates an empty Array.
@m = Array.new(4)     # Creates an array with four empty (nil) elements.
@m = Array.new(4, 0)  # Four elements all zero (needs care if the element is not numeric)

The reason that your code and @newdsp's code both work is because the event method is assigning a new value for @m at every Midi event anyway, and prior to this happening @m isn't processed in any way. In fact, you could have assigned anything, or nothing at all, to @m in the init method without it making any difference, because Ruby variables differ from DSP/ASM variables in a couple of important ways:

1) You don't have to declare Ruby variables at initialisation to reserve space; they're just created ad-hoc when the first assignment happens. Of, course, you still should initialise them if you need them to have specific values at startup! Reading an unassigned @instance_variable (the persistent kind) will return nil. Trying to read an unassigned local_variable is an error.

2) Assigning to a variable doesn't fix its value type. The same variable could hold an Integer one moment, and an Array of Strings the next; Ruby just doesn't care. Naturally, as a coder, you should care! - being consistent is jolly helpful, though switching types does have its uses (e.g. Pens and Brushes are interchangeable for GUI drawing methods).

BTW, creating the Array and a new Midi object is redundant and quite wasteful in this case. Sending out the same Midi object (when you need to) is fine, and you can test the key data values directly. Here's a neater example (though the sent Midi objects aren't so Christmassy! :lol:

)...

Code: Select all

def init
  # Checking multiple static values is quicker, more legible, and shareable using an Array.
  @ghs_keys = [67, 69, 71, 72, 74, 76, 77, 79, 81]
end

def event i, v
    # If the incoming value is a Midi object, we don't care where it came from!
    if v.is_a?(Midi)
        # '.include?' returns true if the argument value is anywhere in the Array.
        if @ghs_keys.include?(v.data1) || @keysw == v.data1
            output v
        end
    end
end

NB: Syntax: Don't space out or omit the question marks of .is_a?() or .include?() - they are part of the method names, not separate symbols; Ruby uses this a lot for predicate [true/false question] methods. Also, prefer boolean && and || over and and or - the latter have unusual precedence rules in Ruby; it's rarely a problem in practice, but that just makes it all the more perplexing when it does bite!

Posted: **Thu Dec 17, 2020 5:27 pm**

Wow thanks trog (as always!).

I did think my code was inelegant but as others have noticed before, I’m a pragmatist and if something (finally) works and works reliably I’m happy to move on.

But I do wonder if there’s something actually detrimental in my code, maybe CPU cycles used or some other unintended consequence…

Posted: **Thu Dec 17, 2020 6:33 pm**

In 306 I'm seeing the same errors repeating in all scripts. It says:

NoMethodError: (in method 'event'): undefined method 'to _array' for nil: NilClass

Here is the broken version saved from 306. I disconnected the broken module but It's still on the page. It give errors as soon as I reconnect it. Even after making those changes there is no sound. The errors go away but still no sound.

Posted: **Thu Dec 17, 2020 7:25 pm**

newdsp wrote:NoMethodError: (in method 'event'): undefined method 'to _array' for nil: NilClass

Ah yes, I've seen this before, either at startup or when copy/pasting. I don't know why, but the 'event' method sometimes gets called from one or more inputs before any valid events (i.e. here Midi) have been received. This makes the 'v' value nil - which is not a very useful value!

To fix it, you can do what I did in my previous example - test that the 'event' method actually received a Midi object before doing anything with 'v'...

Code: Select all

# Replace this...
if i == 0

# With this...
if v.is_a?(Midi)

Spogg wrote:thanks trog

No problem - it was nice to write about coding for a change, rather than forgetting why I came here after deleting hundreds of those bloody "Where is Adminstration..." spam posts again! :cry:

Spogg wrote:I do wonder if there’s something actually detrimental in my code, maybe CPU cycles

Creating duplicate or unused Ruby objects will cost CPU, yes (as will Ruby's "Garbage Collector" when it later destroys them for you). How much depends on how many objects and what kinds they are; e.g. big "containers" such as Arrays are worse than single Integers. Is it enough to be worth worrying about? - I can't tell you, because "enough" is very subjective! Generally, I'd say there are three kinds of optimisation:

1) Experience tells me that there's a well-known "best-practice" for doing what I need to do, or that, of the possible solutions, one stands out as raising the least red flags. Unless it's oodles of extra work, it would be silly not to just do it that way right now.

2) Oh Shit! Look at those CPU spikes! What the hell is doing that?!

Time for some digging around. IF I can identify the problem, and IF there are some likely optimisations, try improving things - then retest to make sure that I actually did improve things!

3) This might come under "unintended consequences"...

Coding guru Martin Fowler wrote:Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

This is about "monkey brain" CPU cycles, not silicon ones. Descriptive code is much easier to debug and to add new features to - especially if you're collaborating on it. It can even be worth sacrificing a few CPU cycles for readability sometimes. Working out what a list of opaque "magic numbers" represents is much easier once it has a name (@ghs_keys) and you can tell what it's used for (filter "white-lists" tend to "include?" things). It does require a certain level of fluency from the reader and, more so, the writer to be effective, though.

Posted: **Thu Dec 17, 2020 9:36 pm**

We love it when your 'Inner Programmer' speaks to us ...

Thanks TROG 8-)

DSP Robotics Support

The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.

Re: The Quilcom SIM-BP: Simulate bagpipes. If you want.