Question (using external to .dll bitmap images?)

[Ricciardo]

Hello flowstone forum users, i am a Fruity Loops user, and i have been messing around with FL version of flowstone...
i have registered in your forum for the porpuse of making this question...

i wonder if its possible to use a path with bitmaps, instead of load the bitmaps and save them inside the .dll...

i have been trying to know more about sysfolders, and start folder primitives in order to check if this is possible but i havend find much information, i have been on the old synthmaker forum trying to also find it, but it i didnt found any example or text information in how to do it...

i also wonder, if with the new ruby implementation is now possible to do it?

but unfortunaly i dont know much about coding, but if i just had an example, perhaps i could understand the process and starting using a starting folder with data for the plugin, instead of using everything inside the .dll, turning the plugin more eavier per instance than it should...

by the way, this is my new prototype,
http://s10.postimg.org/mute2kcu1/shot.png , i am using PNG files for doing everything, and thats why this represents a major "load" in the memory, the plugin it self is so far very light (less than 3000 components) as i have being cuting in everything, inluiding using only a source to load a knot bitmap for every knobs, but if i just learn how to use the external path way, that would represent a HUGE advancement and turn the plugin really light, as i could also start loading binary´s for waves and other sorts of data externaly...

so i would apreciate the help, and tank you for all the users who have been sharing modules and examples, i learned from all of you, i collected more than 200 OSM examples and that was my starting point.

[Ricciardo]

Ups, what way to start...

i double post a topic (sorry)

[trogluddite]

Hi Ricciardo, welcome to the forum.

i double post a topic (sorry)

No worries, mate, we've all done it!

What you want to do can be done, but it is a little bit tricky.
Loading a bitmap dynamically is no problem, you just need to supply a path, and a trigger (e.g. 'After load') to start the loading. Folks have used this before to allow 'reskinning' of their plugins by just dumping a load of new bitmaps into the right folder.
However, the regular bitmap primitives always remember their content, and as you've probably seen, there's no 'clear' input to remove the data - you can only overwrite it with a new bitmap. This makes saving a .dll with 'empty' bitmaps rather tricky!

But there is a sneaky way...
The primitive 'Bitmap Array' does have a 'clear' input, allowing all the current data to be cleared just before you save your plugin. 'Bitmap Get At' is then used to obtain the bitmaps from the array and feed them to your graphics (you could use several arrays containing only one bitmap if filling the array is troublesome).
You would have to modify the code for many of the graphics components too. Most are based around Ruby code these days, and it will throw a wobbly if you feed it empty data. The trick is to find the 'draw' routine in the code, and add a line to skip the code until a valid bitmap is loaded.

Here's a very quick example....

Clearable Bitmap.fsm

(582 Bytes) Downloaded 1590 times

If you look inside the display module, you will find the special code line...

Code: Select all

return nil unless @bitmap.is_a?(Bitmap)

...this would have to go straight after the 'def draw' line - and you have to watch out, because in this case, our bitmap has a nice obvious name '@bitmap' - other controls and displays might use a different variable name for storing the bitmap (often named after the Ruby input where the bitmap is connected). With this line of code in place, anything other than valid data causes the drawing to be bypassed gracefully.

For your path, I'd suggest using either the 'System Folders' or 'Start Folder' (same as the .dll) primitives. A simple 'String Add' can then be used to tag on the filename and extentsion (don't forget the '\'!).

Hope that gives you a start - it's a friendly place here, so just post again with whatever new questions you have.

Happy Flowstoning!

[Ricciardo]

Thanks, you just made my day!

i will share this information on Image-line forum, as i was also asking there!

[trogluddite]

You're welcome.
The guys from the ImageLine site who like to tinker with the FS stuff will get a good welcome here if you want to invite them over - the more, the merrier!

[Ricciardo]

by the way, you gave me another idea...

instead of load all the bitmaps externaly and have to clean them, how about since its a bit tricky, to load only one main file with all the elements as you said flated up like this...



but then, i would had to use another code lines to discriminate the width/height selected on the fil right?

def draw v
return nil unless @bitmap.is_a?(Bitmap)
v.drawBitmap @bitmap,[0,0,@bitmap.width,@bitmap.height]
end

def event i,v
redraw 0
end

i was trying to mess with the numbers @bitmap, i was per example using negative values at width to make the draw came to the left, but then if i need also to cut some pixels at right, i hadnt any way to do it...

like per example, on a file with 400 pixels width, what i wanted selected was the part between 205 and 220 ...
the X, Y, quordenates

[trogluddite]

Yes, it can be done that way. I've never done it for all of the images of a whole plugin - but sometimes I use up/down = knob position, left/right = different colours etc.

To get only a small piece, you need to think of two things...
- Where does the piece begin? - X, Y co-ordinates.
- How big is it? Width and Height.

For example...
If you want X from 205 to 220, Y from 75 to 100
X and Y are easy, just the start positions...
X = 205
Y = 90
Width and Height you have to work out by subtracting...
Width = 200-205 = 15px
Height = 100-75 = 25px

Then the command is...
v.drawBitmap @bitmap, [X, Y, Width, Height] -> v.drawBitmap @bitmap, [205, 90, 15, 25]

The bit in [brackets], an Array in Ruby, you will see often for the graphics commands. Four numbers [X, Y, Width, Height] - called an "area". Same thing is used if you want to draw a rectangle, circle etc. on the screen.

The @bitmap.width, @bitmap.height, you probably don't need - they are only used to find out the size of the bitmap if you don't already know. Good for the 'toolbox' controls, because any old bitmap will work. But for your custom bitmap, you already know your positions and sizes.

Also worth knowing - in FS, Y=0 is at the top - not like many graphics software where 0 is the bottom.

[Ricciardo]

i was trying your second line, but instead of selecting parts of pixels... its ratter deforming the image

i was checking also more information about how to work with "areas" and i ended up with this
http://www.synthmaker.co.uk/dokuwiki/do ... itmap_area

i think i will soon find a logical easy way, if not with a code i will get there using a "source area"
"
learned a lot today

[trogluddite]

Oops, my bad!

Yes you're quite right - the Ruby command you want is "drawBitmapSection'. For 'drawBitmap', the area is just a location on screen to put the drawing, and the whole bitmap gets stretched to fit!

'drawBitmapSection' needs some extra values too - a position on the GUI where to draw it. You can use another 'area' to define this, in which case the bitmap gets stretched to fit the 'destination' area. But, if you don't want the stretching, you can give just [X,Y] for the position of the top. left corner. For simple knobs, where there's only one control on the module, you can usually just use [0,0] - e.g....

v.drawBitmapSection @bitmap, [X, Y, Width, Height]. [0,0]

[Ricciardo]

meanwhile

i managed to sucessfully implement dynamic background on vsti with a start folder!

i also did many testing, i discovered that old OSM. examples i had from another projects are much heavier
tan current examples made on ruby...

so initialy my plugin wich had no more than 3000 components and a fair simple DSP architecture as consuming
4-5 cpu usage, and around 30/50 mb per instance...

after the dynamic implement, and i also started to use the new animated knob, (this was a problem... because old knobs worked only based on pixels, and now this one works with 0-360º rotation... and due to this i had to re-adapt my Knobman projects... but no worries, it was easy as i seen the code!)

but anyway, all this implemented stuff i did after your explanation... made me drop the usage of memory considerably on the plugin, it is now using only 10/13 mb per instance, it loads much faster, and i am allready wishing to also made it work with knobs, and possibly also turn the DSP lighter with some files loading from start path too...

so far very good, but i am allready thinking in finish the DSP schematics, and then start thinking more deeply on the GUI aspects...