bitmap-strip based knob - possible?

Shifrin · 9 Mar 2005

Sure you can make knobs with bitmap-strips 🙂

Updated image this time a lot tidier and all the ins/outs are clear!

Ok, the main parts of the schematic are the DragY and BmpArea. The DragY component has a specified area given in grid units (8 pixels to one grid unit in my case hence for a 32 x 32 pixel knob this equates to a 4 x 4 grid area), a minimum and maximum value, which I have as 0.0 and 1.0. And the 'Scale' parameter which specified step size (or something like that - smaller numbers equal more fine-tuning/the negative sign means if we drag the mouse up the value increases, if it where positive the knob would rotate counter clockwise when dragged up!).

The output of this is multiplied by 50 (the number of images in my knob-strip - 1). This is fed to an 'int' data component to truncate it and then multiplied by the height of my knob, 32 pixels (my knob-strip is vertical). Now I have an offset into the knob-strip image for a given knob position.

This info is used to get the offset into the source image for the current knob and then plugged into the BmpArea component (I think of this as a BitBlt sort-of thing!).

One thing to note, I realised through trial and error that the coords for the 'src' input of BmpArea are given in pixels, the coords of the 'dest' input are given in grid units!!!

If you want I'll put up the .osm file 🙂

Shif.

Shifrin · 9 Mar 2005

(even after years of using phpBB forums I can never remember if editing a post bumps it too - so here is a bump)

Shif.

jorge · 10 Mar 2005

Shifrin wrote: (even after years of using phpBB forums I can never remember if editing a post bumps it too - so here is a bump)

No, editing doesnt bump it so your bumping was very useful.

It's great the way you figured out things including the way the BmpArea uses pixels for source and gridsteps for destination. The only tiny thing I'd change would be to use a RedrawArea instead of a Redraw. For a small front panel you wont notice the difference but for a big one the RedrawArea would be more efficient as it would refresh only the required knob area instead of the whole front panel.

lalo · 10 Mar 2005

Shifrin wrote: If you want I'll put up the .osm file 🙂

Shif.

great Shif! i'd really like to have the .osm 🙂

btw..the jpg here is not visible today

lalo

stefan · 10 Mar 2005

Great work Shifrin! Nice to see people helping each other out as well 🙂

mindplay · 10 Mar 2005

thank you so much! 🙂

maybe you could put up the file?

and with your permission, maybe Jorge could include this as a standard component with the next Synthmaker distribution, for everyone to enjoy? 🙂

malc · 10 Mar 2005

mindplay wrote: I can't even figure out how to feed the "bitmap file path" input - there is nothing connected to it, for example, in the Knob component ... how did it get set in the first place? Do you have to use the file dialog component, and then delete it afterwards? Seems a bit clumsy ... would seem more intuitive if you could just right-click and choose "load" from a popup menu or something, but that doesn't seem to be possible?

This is a good point. The Bitmap component stores a bitmap inside it. You load this in using a file path that you connect to the string input. You can use a String component and type the path yourself or (as you've suggested) you can use the File Dialog component. To execute the loading of the bitmap, you'll need to send a trigger to the load input of the Bitmap component.

As you've seen, once this is done the bitmap component can be disconnected from everything and it will still retain the bitmap data. The bitmap is saved with the schematic file so if you share it or create a VST dll the bitmap information is retained. If the Bitmap component relied on the inputs to load the bitmap data each time then your schematic wouldn't work if you shared it with someone else (unless they happened to have the same bitmap file in the same location on their hard disk).

This way of working may indeed seem clumsy but the reason for it is to allow maximum flexibility. The improved way of doing all this that you suggest is then easily possible by creating a module, and that's exactly what we've done: have a look unter the Control group in the toolbox. You should see a Bitmap module. This allows you to easily load a bitmap by clicking on the module's panel and choosing a file from the resulting dialog.

You can modify the Bitmap module so that it passes the bitmap to a bitmap output that you can then connect to the Bitmap Area component to do your animated knob.

I hope this helps - let me know if any of this is unclear 🙂

Incidentally, the knob component was created before the Bitmap module was created and we haven't updated it to use this yet to use the Bitmap module. If we had, perhaps it would have been more obvious to you what was going on - of course maybe if we had some documentation that would help 😉 (coming soon I promise )

malc · 10 Mar 2005

mindplay wrote: and with your permission, maybe Jorge could include this as a standard component with the next Synthmaker distribution, for everyone to enjoy?

We always planned to have a good library of higher level modules that you can modify for your own use. At the moment all we have is a small collection of GUI modules (slider, knob, bitmap, label etc.).

The framework is stabilising nicely now and so we'll soon be in a position to do this. I hope (like the lack of documentation) this isn't too frustrating for you at the moment.

Shifrin · 10 Mar 2005

Here's the .osm :-

KnobStrip.osm

I've changed the Redraw to a RedrawArea thanks for the tip Jorge 🙂

Shif.

mindplay · 10 Mar 2005

malc wrote: The improved way of doing all this that you suggest is then easily possible by creating a module, and that's exactly what we've done: have a look unter the Control group in the toolbox. You should see a Bitmap module. This allows you to easily load a bitmap by clicking on the module's panel and choosing a file from the resulting dialog.

handy! 🙂

and there is no performance penalty for doing it this way? I mean, these components are not actively performing any other actions during realtime processing?

and by the way, thank you for communicating so actively with us users - this is not something that most developers take the time to do, and I appreciate that very much!

jorge · 10 Mar 2005

Shifrin, if you ever need a place to host a file, just email it to us and we'll upload it to our webhost, the same goes for everybody else.

Also if you dont have time to do a screen capture, just email us the schematic with a description of the screen capture you want and we'll upload the image.

You can always do your post without the screen capture and edit it later once it is uploaded.

jorge · 10 Mar 2005

hi mindplay

mindplay wrote: and there is no performance penalty for doing it this way? I mean, these components are not actively performing any other actions during realtime processing?

Like I just explained in the other thread that you started, the poly/mono processing is compiled while the other types of data work with events and triggers and cause some processing only when something changes. The two are independent, most of the time only the sound compiled code is running, then if for example you move a knob, it generates triggers to update some value used by the machine code, as soon as you stop moving the knob, no more processing is done related to it.

So basically, the answer is no, these components are not actively performing any other actions during realtime processing unless you're in the middle of interacting with them like for example moving a knob/slider. When you're interacting with a GUI component, the processing stops when you stop interacting. Also the efficiency of the GUI modules depends a lot on your schematic, if you do things right like using RedrawArea instead of Redraw for example, it should be quite efficient.

jorge · 10 Mar 2005

One more thing, I think Shifrin is using SM's internal version 0.9.1c, I'm not sure if his schematic works with previous versions. Should work with the next beta release anyway.

Shifrin · 10 Mar 2005

jorge wrote: Shifrin, if you ever need a place to host a file, just email it to us and we'll upload it to our webhost, the same goes for everybody else.

That's very kind of you cheers 🙂 I do have some webspace which is more than adequate for .osm files etc but I don't know how much bandwidth I get (probably not a lot, but then again probably enough!).

Shif.

stefan · 10 Mar 2005

I'd recommend using rar for packing the osm files. It does a way better job at it than what zip does, my 1meg osm file gets compressed to 34kbyte with rar.

lalo · 10 Mar 2005

thanx Shif 🙂 i learned a lot 🙂

lalo

ik_ik_ik · 10 Mar 2005

Yeah. Thanks Shif and all. A really useful insight into some interesting corners. It will save a lot of pondering 🙂

Inigo

Shifrin · 10 Mar 2005

stefancrs wrote: I'd recommend using rar for packing the osm files. It does a way better job at it than what zip does, my 1meg osm file gets compressed to 34kbyte with rar.

Yeah rar is the way to go - I'd have packed the little example I posted but it was only about 50k anyways so just left it.

Oh yeah, the .osm was saved out of the 0.9.1c internal version.

Shif.