DSP Robotics Support

Taking my "Super Text Box" as a starting point, here's a little preview of what I've been working on over the summer (when the sun hasn't been out of course!)...


(the mouse pointer will give you some hints what it can do! )

Hoping to marry this up with my XML classes once I have the API a bit neater and easier to use. Let me know what you think - I'm always open to suggestions for killer features!

NB) Requires FlowStone 3.0.3 "Raindrop" - seems to crash earlier versions; it uses the brand-new Ruby edit box and drop list features.

Back soon...

Wow..Really interesting.....really hard too!!....
First brief look.....looked for a way to fill the arrays...
Didn't see a way to feed values in other than by text edit...
still searching for the hidden door...... ..dammit...how did he make this thing....

billv wrote:Didn't see a way to feed values in other than by text edit...

Cheers, Billy!

You're spot on with your comments - ATM, I'm just making a random table using the Ruby methods so that I ca debug the new classes.

There's a few ways I'd like it to work...
- Modules for the non-Ruby folks - bit like a string array prim' with string input parsing, and some "Get", "Set" modules.
- Editor modules for the field parameters and GUI box set-up. ESSENTIAL! - needs an easy way for folks to define the parameter ranges, table layout, GUI style and mouse interaction.
- Save, Load of tables. Save, load can be done quite easily with Ruby's "Marshal" commands, but they generate unreadable "binary" nonsense, so I reckon XML is the way to go.

Week off work next week - so hope for rain!

Thanks!
This is realy Useable

It did get out an old module from me and did now a ruby draw - Well the problem is - i'm an oldschool user ^^
So i always split up ruby in more single modules and do not define anything with custom classes.

I've said alway, that FlowStone is a verry useable progam - if you do not to much with looping views.
But this gets better with ruby so i built up my old module with ruby yesterday and got a lot of more performace that is much faster. But i would not upload it - first, this is much better if it is finished.


Some questions to you trogluddite:

Why do you want to marry it with XML? - How about the idea to built up a Databaseprotocol like MySQL?
Then you are able to view/edit and all what is possible with your table load it into the database
After that the database could be accessed with any operation modules and add here for example XML Load/export - TCP-IP Sync (I could try to add the variable-Server)
What the database need in this case would also be a "Skript-Trigger" so that you are able to execute any string-script within the database doing operations. This string script is verry useable if you want to execute some code that comes from another TCP-IP client.

Well i know this are not things that could be done now next night^^
But if we could get "one-strait-line" to flowstone again this would be too awsome

What do you think about that?

Regards

This is some serious work here.

I was interested in looking inside ... wish I was able to comprehend this, as this looks very useful ... at least from the GUI side of things .... I've always like 'pretty pictures'

Admire your work and knowledge TROG.

Thanks guys,
Still a long way to go with this, but it's great to hear your positive feedback!

chackl wrote:Why do you want to marry it with XML? - How about the idea to built up a Databaseprotocol like MySQL?

Very interesting idea - I must admit that this hadn't occured to me at all.
I suppose I'm just showing my bias towards saving VST plugin preferences etc. - and my complete lack of knowhow with SQL (I sort of know what it is, but that's about it!).
I liked the idea of XML for a couple of reasons...

1) Human readable 'text' in a commonly accepted 'standard' format.
2) Unlike the regular preset manager etc. it can easily handle text formatting, most Ruby data types etc.

I think that, in the first instance, XML is the way I'll go - setting up a database just for a few VST parameters would be overkill, and awkward for the end user to set up - but I certainly wouldn't rule out SQL. The possibilities then are mind-boggling - I could see a whole load of application just in telemetry/data-logging alone - and SQL would save us from having to 're-invent the wheel' in so many ways.

RJHollins wrote:wish I was able to comprehend this

Well, hopefully, there shouldn't be too much to comprehend when I'm done! Once finished, I'll put together a little "API document" that defines how each class works and how you talk to it - much like the FS use guide describes the bullt-in classes like GraphicsPaths, Brushes etc.
Whether using classes or not, probably the most significant thing is to note that you don't have to put all of the drawing into one big 'draw' method - so long as you pass on the View object, you can break down the drawing into many smaller methods - writing and testing smaller GUI elements in isolation and then combining them into the overall GUI.
Breaking the problem down that way makes it much easier to manage, gives you some nice cut-and-pastable code snippets, and usually results in more readable (and bug-fixable!) code.

For example, here's a simple one that draws crosses wherever you like...

any advice on how to perform the reordering with drag and drop?