DSP Robotics Support

ahhhgg ...

It looks like the Knob that got all the mods [snap, default, etc], is different from the stock 'Animated Knob'.

Now it seems the 'Animated Knob' needs the RUBY code modified.

So I thought, fine, I'll track down the change ... copy/paste them in. ......... right. Nothing THAT simple.

The 'Ani-Knob' has other routines in there ...

So before I ask ... WHY are these knob routines different ... AND, Am I the first one to try and use the FS knobs ???
I half expected that the FS knobs would at least match functionality from the SM versions ...

Anyway ... the drag is that already, so soon ......... I need big time help for this

I'm posting the 'stock Animated knob' here ...

Geesh ... I feel like a pan-handler coming back for 2nds and 3rds ....


---- oh ... then reading TROG's post explaining the 'global' impact with RUBY. So the concern is ... will these mods on the knobs be isolated [each with there own steps, snaps, etc] .... if not, that would be major problems..

anyway ... sorry for my frustration with this early start.

Thank-you.

another edit ...

I pulled in the Animated Knob from SM, and added the FS Gauge module to it. I guess this is what everyone has done.
Seems to work alright.

From the positive view ... my ... the different in the visual quality/clarity in the display around the knob is way better than KnobMan generated. I will probably redo all knobs and can use a smaller font and STILL have it more readable. This is fantastic.

There are some 'tweaks' I would like to get on the 'Gauge' module. Things that could be fed into the RUBY code and allow for customization without having to rewrite RUBY itself.

We should be able to optionally choose if we want the minny ticks and/or how many. Choice of separate colors, control of spacing [radius]. Things that would be allow full control, yet minimal or no RUBY code change.
I'm so glad that this important GUI feature is here!

sorry but I missed what would you do .... My problem in understanding English.
you may only want to have more options without changing the code ruby?
what you mean by impact of Ruby?
Trog what he said, gently, a link on this?

I think the difficulty to start with the new FS,
lies in the fact that when you make changes in ruby​​, it is always a personal concept,
in ruby ​​you can do the same things in different ways, some more efficient than others,
I I think it starts a process of minimal sharing, and participation in the community,
because more than anything else you can share a concept on programming and a few tricks,
but then always depend on how you've set up all your ruby environment,
then you lost a little bit the classic concept of object-oriented programming with SM,
but it has opened a new concept, the programming of the objects themselves,
and then use them in the classic way, but then some will not want to have so many moduls,
then you will implement functions in ruby​​, then use a few RubyEdit to create more complex routine,
but eventually you will know about your environment with integrated functions, developed, changed or added,
and will not always be shared.

you need to copy just the code parts which do the snap and default to the same places like in the other knob and whats important is that you need a floatinput for the steps because when you divide the to_step thruogh @steps you want a float value but to_steps is an integer (wich we chaged to int with .to_i) so if @steps is an integer too the result of the division will be an integer too but if the @steps input is a float value you get a float out of the division and it works right , i commented the parts a bit better that yuo see where the codeparts are

the only thing which is not like perfect is that when you choose snap and the dedfault value is not one of the snap values the default value on output is the actual default value but the knob is drawn on the nearest snapposition or on the closest snapposition before, not shure exactly didnt test that... but everything else should work fine also whith this knob

RJHollins wrote:
We should be able to optionally choose if we want the minny ticks and/or how many. Choice of separate colors, control of spacing [radius]. Things that would be allow full control, yet minimal or no RUBY code change.
I'm so glad that this important GUI feature is here!

you find all the important variables ticks, major, radius... right at the biginning of the ruby code of the gauge just make inputs for it and say r = @radius (if input for radius is called like this) and so on like this you can connect themto the "outworld"
you also can make a input for a second colour and use it to draw the label so you have one colour for labels and one for the ticksjust search the code for @colour and change one of it to your new added colour also the font and its size is changeable search for the font variable...

Thank-you both !

I'll definitely be looking through the Gauge RUBY code more.
I've experimented with sizing and various colour settings already.

As it is, the Gauge code, though working, is written in such a way that makes customization extremely limited.
Of course, MY impression is based on the same 'extremely limited' knowledge of RUBY. so that must be considered.

Ideally, I would like to see the 'Gauge' module rewritten to allow more control of the various elements. Items like:

a. the number of small ticks, large ticks [with option to turn off either one]

b. spacing. With this I'm referring to the 'radius' distance that the 'numbers' get placed from the 'ticks'.

There is more ... and I should put together a diagram that would better show what I'm trying to explain .. I'll do that.

Very Important ! The posting by TROG regarding RUBY stuff. This is the thread I was earlier referring to:
http://www.dsprobotics.com/support/viewtopic.php?f=2&t=1117

take a look at the Vintage Meter.
it is not installed with the default installation.
you must download it from the forum, the Modules section.
there are different categories, the Vintage Meters, is located in the Audio Pack.
it has a gauge with other options available, you can take inspiration and learn a bit of code,
looking at the differences of the two gauges.

yeah good idea, so i just did it ..

about ticks and major(ticks), they are connected together by modulo so if you dont want to show ticks in between the majorticks just set the major to 1 then there are no ticks in between, i put a second color for labels, you can turn labels and ticks on and off, choose the size and thickness of ticks and majors, you can change the radius and finally the fontsize, watch the code you will find everything i changed pretty fast, i commented it... have fun with it


edit: yeah i was stealing your learning by doing part

RJHollins wrote:
Very Important ! The posting by TROG regarding RUBY stuff. This is the thread I was earlier referring to:
http://www.dsprobotics.com/support/viewtopic.php?f=2&t=1117

if i understood everything right this is only important when writing your own classes to make unique namespaces for them to get not in conflict with classnames from other people... but till there for me it will be a long way and i think you dont need to take care about for now..

Yes, Nubeat is correct - namepace clashes can only happen when certain kinds of Ruby programming are used. For the vast majority of code, each RubyEdit container is totally isolated from all the others.

There are only really three things that the namespace problem applies to - classes, modules and global variables (global variable begin with '$' - and if I catch you using them, I will come looking for you!! ).

When you are programming something yourself, then naturally you will know if you are using any of these things.
It is possible that you download a module written by someone else that contains a new class or module; and the guidelines in my other post are intended to help people doing that sort of thing to program them in a way that doesn't cause any nasty surprises for anyone else.
But you can do a hell of a lot with Ruby without ever touching those aspects of it, so don't let it scare you into not having a tinker!

PS - Nice module, Nubeat - that looks very handy indeed, thanks!

Hi TROG,

Thanks for stopping in and confirming NuBeat's post regarding YOUR post
As NuBeat related, yeah ... I don't think I'll be churning out any RUBY 'class' stuff anytime soon

More importantly, I'm a little more clear understanding about looking to use RUBY in my project.

Last Nite I was going through some of the RUBY graphics tutorials in the manual. The thing I was doing was rather straightforward, and the RUBY coding made sense to me. I played around with the 'GraphicsPath' concept as well as the 'path.addLine' commands. I don't know ... maybe for the small test I was doing, I don't quite see any 'path' advantage ... but over time that might change.

The 'GAUGE' module that NuBeat has been modifying has been very nice. Personally, I would still like more flexibility in this section. What NuBeat has already done has greatly improved the 'stock' routines, and has also given me a glimpse into a piece of RUBY. I still need much more learning of this. Right now, the 'GAUGE' has a serious limitation, in that it was based on a 'TICKs' Do..Loop. The 'Major Ticks' would normally be those that would get a label ... but you can't eliminate the small ticks, else you get no Ticks at all. There is also extra math needed to get all the Majors labels to display. As mentioned, the original code had a different base concept. Trying to modify it to work as I'd see requires a pretty good RUBY knowledge ... 'cause it would need a re-write based on a different display concept.

I'm definitely going to try some coding on this, because every project that I can think of will probably have some kinda knob needing a Gauge.

The other thought ... maybe a 'Community Effort' on such a fundamental GUI necessity !

Regardless ... the FS advantages are starting to get clearer to me. I'm not looking to become a professional coder by any means [even though I want to get good at this]. I need to get my Beta to the testers, along with documentation ... but I'm looking to go FS in full for the release. The improvement in the knob displays using NuBeats' modified Gauge is so much better than the KnobMan text graphics. I cannot ignore that.

Anyway ... most always, enjoying your postings! You may get tired of hearing it, but you have helped me out more than you'd ever know. Your SM 'ToolKit' has been a treasure of programing power. The 'Auto Numbering Arrays' is just one small example that made a huge impact with my project ... oh, and the 'BUSing' concept allow me understand so that I actually integrated it into my merging of 2 programs. So thank-you ... you really are a wonderful Teacher.

Sincerely.