How best can i simplify "Redraw"?

[Matth23u]

I'll make a quick EXE of what i'm trying to put together as an interface. It's an "akai midikix" relay that makes the whole projects record automation based on a relay interface instead of the haradware thing... Plus, it allows me to integrate some mathematics. Tho, i so badly need FlowStone to upgrade VST export so it could see "FL Studio Midi in/out"
I'll show you a basic preview of what i'm into...

I, right now, am trying to render all knobs a layer above, in a single view, and to make knobs align themselves automatically, but i'm unsure if it makes sense.
The problem that i get there is that it aligns from centre instead than on grid from left to right.
Every instances of "knob" increases by "1x" to set it's "CC" and "Preset name" and "display label" and i use that value to evaluate on a grid where the knob should display so i used bitmap stripe height and cell width through the module [G]ui's own width and height. Tho, i want to make the whole thing count the total knobs that can fit in the viewport's width, align all knobs from left to right.

I managed to make 1x "Gui" primitive for all knobs by making a custom transmitter abbreviation and getting all knobs to channel the same receivers's channel.

Hmm... There's another thing. You'll see in the EXE that there are cracks between modules. Is there a way to make background grid all black... Or to make-so the color on the knobs bleeds out in a sense?

The problem really is that it's out of fit... And i should really find a way to combine a maximum elements into a single complex process which i'm getting close to.

A single display for all knobs....

An important project that i want to get into is to make multiple preset slots and have full control onto those.
I'd need these for my "preset fader".

You'll see.

http://www.nightmaredream.com/up/Preset ... Simard.zip



Oh... The way preset fading works is simple... Pronounce at least 2 words from the magic incantation sentence and don't pronounce it wrong. Perform the ritual as it goes: Select a preset and set it as you will, press write just to be absolutely sure that it'll keep changes in memory, then switch to another preset. Press "config" and "Set all on" and slide left and right the preset-fade slider.

The whole thing doesn't contain anything practical yet, but i need to be able to export VSTS that DO have midi in and midi out like it should have... "FL midi in", "FL midi out". Synthmaker is an amazing software and it have so much potential. It's worth developing ever fine bits.

What i would do next, as exporting this as a VST would be to put a "Midi CC out" for every knobs. But it's currently useless as it can'T select the right midi in and midi out... Or do i do something wrong?

How should i normally make a plugin similar to "Cthulhu VST" or "chordz" or maybe make a controller plugin like "Fruity LFO" or "Fruity Peak Controller".

Basically, this should be an effect synth. And it should be combined with a Generator synth and both should communicate together. It's doable with live schematics, but once exported as VST, stuff doesn't stick together... Just like the magnets in "Stranger Things 3".

i thought... Shouldn't you guys make a "Gui" forum section? Somewhere "all things gui" could be discussed?

[Spogg]

Wow! That’s one weird and fascinating GUI and I love it!

Unfortunately I don’t really understand some of your points and questions.
It would help if you could break this down into single bite-size questions and issues and post them individually when a question has been solved.
Plus I would need to see a schematic to be able to offer any help, and I think others would feel the same. You could make stripped-down schematic versions that illustrate one issue and we could try to resolve that, and then move on to the next.
I think that’s the best way forward.

I can answer one point for sure. Moderators have no privileges to amend the forum’s areas and organisation. This has come up before, and I agree it would be nice to have GUI, Ruby, ASM etc. sub-forums, but you’d have to ask DSPR (Malc) to do that.

Regarding MIDI in/out, were you aware you have to incorporate a MIDI input selection prim for an exe? I don’t have FLS so I don’t know how this would integrate with it. I assume FLS can provide a MIDI “driver” source that other apps can see and connect to, otherwise you’d need a MIDI routing app. Plus, I don’t personally know how an exe’s MIDI output can be accessed by other apps, or even if it’s possible. Hopefully someone else can answer that one.

Cheers

Spogg

[trogluddite]

Thanks for the example and the explanation. I think I understand better what you're trying to do. Usually, to make a grid of controls automatically, you'd use a Draw Loop to calculate and draw them; but in that case every control is always redrawn even if only one of them changed. So you're quite right; it would be better if there were a way to redraw only the moved one. If a way could be found, I think it could be quite a useful general-purpose FS module - a lot of designs have banks of identical faders etc.

I have a couple of ideas how this might be possible - but I need to do a few experiments to test whether they are likely to work.

[trogluddite]

OK, I've done a bit of experimenting, and I think it's going to be possible. Here's a schematic which demonstrates the principle.

[EDIT: DOWNLOAD REMOVED: The next post contains a more capable version]

Each control in the grid gets sent a random value whenever it gets redrawn. When you click on a control, you'll see that only that control gets changed and redrawn. If you click outside of the module, you will see all of the controls get updated - because FlowStone commands a 'global' redraw when you do this, making it necessary to redraw all of them.

A single control is drawn in its own module, and this is then duplicated using the Draw Loop primitive, as you would usually for a control grid. However, when you click on a specific control, it sets the loop start and end points so that only that control is updated, then does a Redraw Area. The loop start and end points are then reset so that if a 'global' re-draw happens, it will loop through all of the controls. The same principle should work for Ruby drawing as well, I think.

It still needs a lot of work to make it into something useful, but I think it shows that what you need can be done.

[trogluddite]

Here's the next stage - the controls now allow mouse dragging, and the module has a Float Array output for the values.
There are two modules in this one; the top one has the new selective redrawing, and the bottom one is the usual method where the whole module gets redrawn. Selecting between looping all controls and only drawing one of them is now done using the mouse-dragging boolean, which actually makes things a bit easier.

Selective Grid Redraw.fsm

(2.34 KiB) Downloaded 1350 times

If I compare them with the Task Manager CPU graphs open, I can see a very noticeable difference in CPU use when I wiggle one of the controls really fast. With the selective redrawing I can add a few per-cent CPU by wiggling a control like crazy, whereas with the non-selective version, I can easily max out a CPU core (this is on my crappy i5 laptop).

[tulamide]

Here's something general for the topic, that people often don't realize as being an issue:

"Size matters."

Modern graphics cards have something called native resolution. It is a certain size that this card was built for. All its components are designed to give the highest framerates for that very reslotuion. A Full HD card may support higher resolutions, but it works best at Full HD.

Windows doesn't have such a structure. It just shifts bits around in a reserved memory area and send it to the monitor whenever ready. Working on a mem area can be compared to working with an array. As you might see, doubling the values of a 100-item array can be done much quicker than the same calculation for a 10,000-item array.

The mem array Windows is working in, relies on the selected resolution. For Full HD this means 1920 * 1080 * 4 = 8 MByte. Luckily, it doesn't need to re-calculate every single byte. Instead it updates only those that changed.

And that's where we come back to the introduction sentence. If you create a view, you can imagine it as a visual representation of a part of the mem area that Windows draws. It you set up a view to draw a rectangle and size it to, say, 100x100 pixels, copy it and set the copy to fullscreen, you will immediately notice the difference. The larger one slows the PC down. This is because a machine has no intelligence. The non-existence of color doesn't mean it will do nothing. It will work through every single pixel that's encompassed by the view, wether you draw something there or not. For every non-used pixel it will write 4 bytes of 0 value.

So make sure your views are as small as can be. Every line of unused pixels is needlessly adding to the CPU load.

This is also true for views that are arranged on top of another view. For those a buffer is used, where both views are combined. The more unused space in the top layer views, the more there is to calculate.

Size matters.

[trogluddite]

Yes, well said, tulamide - especially about all those transparent pixels. The stock controls always make me cringe with their unnecessary extra layer of module GUI which does nothing except show the same as the one beneath. Using modules to group controls is very useful way to keep a schematic organised, of course, so I'm not suggesting that anyone should go as far as trying to eliminate all "wrapper" GUIs. But when they do nothing except clone a single control, it seems rather wasteful (not to mention making many of the stock controls incredibly annoying to re-size when you change bitmaps/drawing!)

[Matth23u]

I've minimalized the whole things, removed the preset fading junk so it's simple and sweet.

Prototype does some kind of overdraw by having the view receiver on a different depth layer than the gui prim.

Tho... I'd really want some clever way to combine all images into one and remove the grey lines between bitmaps in a merged image lime mentioned previously in the suggested methods given as replies.


About midi in out, could you make a minimal "standard" format to let midi work like intended? And it needs to be VST because the magic happens between VST and VSTi between rack instruments and mixer effects... I'm making a synth that depends on having a midi in from inside FL studio just like when synths aren't exported... Tho about FL, i guess you can try the demo and install FL Synthmaker along. You should be able to test around... There's many great things that can be done from inside FL, mainly, performing maths on CCs... Combining FL internal controllers and much more. Say... Imagine... I can use "Peak Controller" that takes any audio input and turn it to a CC... Then combine it with a knob to add velocity to it.. For a simple example...

Took me a few tries to get the audio in and audio out correctly placed inside DSP Robotics's interface so the option "VST" becomes available, in the first place... So maybe i missed some points about midi too.


I've given a try to the adaptable redraw and it is nice, a practical example like this is really relevant! Tho, beyond that, the float array is sent to individual preset and cc set of modules? How could snap, default, min max and other values be set on such a grid? Can the knobs easily be replaced with bitmap stripes? Could i add right click interact easily? I'm looking at this, it seems oversimplified, one set of prims for all knobs, that's exactly what i'm looking for in a sense! As long as i can fit in the necessary preset parts.

Say, if i want knob in row 3 column 4 to be set to 43.2501/100, with such a grid, how is that achieved?

[Matth23u]

lol i finally made it! I made it so midi in and out works... But that implies that i have to exclude having a midi in out selector on the exported synth...

The file is a simple proof of concept.

Tho, how do i do if i want to make multiple midi out ports with different data on different ports? Hmm.. Because i can set only one midi out port with fl studio's synth backend properties...

Tho, that's some great progress i've made there, because i really thought there was no way possible of making it work, but finally i only had to exclude the selectors, outside the module...

Well well... That's nice.

All i have to worry about now is simplifying the gui so it's quickly rendered.

[trogluddite]

lol i finally made it! I made it so midi in and out works... But that implies that i have to exclude having a midi in out selector on the exported synth..

Glad to hear you have that working now. You don't have to exclude midi in/out selectors; it's possible to include those too and merge inputs by joining their links with the one for VST. However you do have to be a little careful - some MIDI drivers will allow communication with only one receiver, so if your DAW is set to listen to the driver, you may not be able access it from a MIDI selector at the same time (it will say "driver already in use", or something like that, when you try to select it).

Tho, how do i do if i want to make multiple midi out ports with different data on different ports?

For the version of VST which FS uses (v2.4), VST plugins can have only one MIDI output port to the host. You can have multiple MIDI out selectors, though - so it can be done so long as you don't need the MIDI data routed through the host (e.g. to be able to record it etc.)

Say, if i want knob in row 3 column 4 to be set to 43.2501/100, with such a grid, how is that achieved??

Yes, that's going to be the difficult part to make, I think. You could just use 'Array Get'/'Array Set' for each control, but I think that might not be very efficient (all the controls would have to check the array when only one value was changed.) Using a VST Preset Array primitive would make storing/recalling all of the preset values easy, but then it would no longer be possible to have different names for each control, which would not be good either! Time for some more experiments!!

Changing the graphics for something else should be relatively easy - the "Draw One Item" part could even use a selector on the View so that each control could have a different appearance; or maybe a Bitmap Array to select different animation strips per-control.

The little gaps at the edges, I've seen before. My guess is that the anti-aliasing tries to "feather" the edges of the Area rectangle when it's redrawn, leaving a slightly transparent strip of pixels at the edges (especially if it doesn't align exactly with pixel edges). There may be no choice than to draw a colour underneath the controls to prevent this, as it may be a "feature" of the Windows graphics engine that's beyond our control.