pattern sequencer; possible with Ruby?

[trogluddite]

Great stuff, billy!
Runs with no issues here - CPU was OK too; even my little Atom CPU netbook managed to run a poly sequence with very few glitches (FS CPU meter was low - so probably the screen re-draws on the crappy built-in graphics).

[billv]

Runs with no issues here - CPU was OK too;

Cheers mate...looks like it was a tempory mistake somewhere...
(for about 10min it was sitting on 20.0 FS CPU.. not sure where it came from or where it went.)

screen re-draws

You were right Trog..the 'money' is in the graphics section....
anything that moves, get it out of green and into ruby and were sweet as..

starting to 'visualize' the mechanics needed for the piano roll...
i need to build a ruby 'double slider" type of control first....
A recent post by Exo showed a nice screen "zoom in/out" type of control...

But still thinking of more seq alt designs, so might keep mucking around there a bit..

[kortezzzz]

Great!!! gonna test it tonight and report. Thanks billv

[kortezzzz]

starting to 'visualize' the mechanics needed for the piano roll...

WOW, almost missed that... that was fast! you are full of surprises lately, man

if any help is needed in designing, I'm here. would love to port the the existing virtual midi keyboard we already have here on the forum (but a vertical edition) at the left side of the piano roll just like at the major DAWs for WYPIWYG
(what you play is what you get)...

[tulamide]

- so probably the screen re-draws on the crappy built-in graphics.

From my past readings on these forums I got the impression that you are one of the few who literally know every bit of FS. Since I always wondered about this point, may I ask what, from your point of view, would be the better graphics building? I read so much about it, but everyone has another view on this. Some say, green is better because it wouldn't crash the app while ruby would. Others say ruby is so much less cpu demanding. And if both are right, it's even harder to decide. Is it better to risk crashes but have better performance, or better to stay on the safe side with over-demanding green but less crashes? I am really insecure.

[kortezzzz]

Great!!! gonna test it tonight and report

billv,
Well, played with it last night by porting a wide range of drumkits and instruments to it (best gem has been playing some ballad riffs with a great sampled acoustic guitar had a real fun!) and not only that, but started to built a full piano roll, based on the "one note seq" module. it's looks, performs and feels great, but... there are few "but"s, and Im writing them only because you've announced that you are modelling a piano roll, so hope you'll find this "but"s helpful
(but you don't really have to take them into account. just my 2 cents).

1)There is a problem with modifying integer values that managed by the ruby code. for instance, any try to modifying the the tempo or the duration values with a "green" knob massage cause the seq module to crash immediately.

2)To get a real piano roll feel, the time line of total 16 notes length should be expandable at least to 32.

4)putting "locators" in the time line would be great stuff!

5) using custom note duration instead of the traditional 1\1, 1\2,1\4,1\8... will be great as well. starting\ending points can be the existing 1\16 and 1\1. the rest can be custom and modifyed with green (if ruby doesn't creash...).


My modeling style, based on the great "1 note seq" is attached

[billv]

Glad your having fun with it...

modelling a piano roll

Na mate, that would take me years at my current skill level. I'was just
thinking out load.

1)There is a problem with modifying integer values that managed by the ruby code.

I can't re-produce the error.
I re-connnected the tempo prim you dis-connected and deleted the green ticker you got in there
still got no error....

instead of the traditional 1\1, 1\2,1\4,1\8

that int sticking out the back of the tempo module that says 16..thats 1/16
so eg: change that to 1/3 and you'll get 1/3

2)To get a real piano roll feel, the time line of total 16 notes length should be expandable at least to 32.
4)putting "locators" in the time line would be great stuff!

Go nuts man and modify it anyway you want....

[kortezzzz]

Na mate, that would take me years at my current skill level. I'was just
thinking out load.

Yeah, it probably will take lot of time . Anyway, we have an excellent starting point here. and we can always put one feature every time. I have some great ideas how to improve the existing concept, and too bad I lack the knowledge to perform it in ruby, but started to dig into the schematic, trying really hard understanding it's logic

I can't re-produce the error.

Confirmed. Today, I had no errors! It's strange... yesterday it crashed a lot, especially when edited manually the duration or the beat speed integers, writing values into them with the keyboard. Today I'v just used knobs for switching values, and got no crashes.

that int sticking out the back of the tempo module that says 16..thats 1/16
so eg: change that to 1/3 and you'll get 1/3

Thanks, I'll try it.

Go nuts man and modify it anyway you want

I'll try to do my best. Right now, I'm just relaying on the given code and using lot of "copy paste"s to understand the logic. Must say,that's very cold water to dive into...

[trogluddite]

what [...] would be the better graphics building?

I don't think there's much to choose between them for graphics per se - high CPU loads are mostly due to the graphics being drawn by Windows GDI+ graphics engine. For example, the shape drawing primitives are doing exactly the same thing as a Ruby call to "view.drawRectangle" etc. - just calling a GDI function with a list of parameters for it to use. The trouble is that GDI uses the main CPU to draw everything without any hardware acceleration from the graphics card.
There's also no frame buffering, so every re-draw begins with a 'blank canvas' - e.g. every time you a draw text label, it is rendered from the fonts even if the text hasn't changed.

To manage GUI CPU load, there are various techniques that can be used - and they all pertain to giving GDI the least amount of work to do. Some examples would be...
- Limiting the number of redraw events.
- Drawing only areas that have changed.
- Limiting the number and complexity of graphical "objects". e.g. a bitmap at its native pixel size is much faster to draw than many layers of vector shapes and text rendered in real-time from fonts.
- Send GDI as many object to draw in one go, then redraw all at once, rather than redrawing it in lots of small sections. Especially true when areas overlap - sections of a background graphic might end up being re-drawn repeatedly when little things that are on top get re-drawn.

From tests that we did when Ruby was first introduced, it seems that primitives and Ruby are about equal so long as you compare schematics that are optimised to the same level, and compare them using the exports so that there are no extra re-draws coming from the FS editing workspace. So I think most folks will get best performance out of whichever system they are most comfortable with - 'green' has an advantage there just because it's been around longer, so the 'best practices' are more established. With Ruby, we're still largely at the "R&D" phase of these kind of optimisations, and many folks are still getting to grips with the language itself - so I think many of the reports of poor performance have more to do with implementations than anything intrinsic to Ruby.

I feel that the FS implementation and guides don't help us much here. Ruby is a very pure Object Oriented language - much more so than C++, for example. But everything in FS encourages us to write code that is much more like a procedural language - it's tricky to use custom Classes of object, for example. So it's easy to fall into what many 'OO' programmers would think of as 'anti-patterns' - for example, creating too many new objects that later have to be destroyed, and not 'encapsulating' data in a way that makes it easy for the garbage collector to manage.
I've been hassling Malc for a while for a few features to make this easier - I don't think that FS benefits from the power of Ruby as much as it could do, because it too difficult to play to its strengths.

yesterday it crashed a lot

Not seen this here - are we talking 'crashed' as in FS crashing, or the dreaded Ruby 'too much processing' shut down?

[kortezzzz]

Not seen this here - are we talking 'crashed' as in FS crashing, or the dreaded Ruby 'too much processing' shut down?

I'm talking about that red-white frame that pops around the ruby module and warns about an error that occured
(Its always reminds me a candy, so let say that the modules has "candied" ).

I think that I have an idea what wrong; noticed that ruby modules that contain graphics are in some cases very sensitive to "toggle minimizing\maximizing". that's why every time I copy -paste a module or make a new module from
these ruby codes, I get candied. possible?...