Delay with gate?

[Spogg]

Here’s the next version.

I think I did what you wanted but this is an on-going project so tell me what’s next (apart from replacing the GUI with a good one ).

I must say the idea of separate delays for left and right was a stroke of pure genius (and uses no more CPU due the mono4 system). I played with that for some time and it’s extended the range immensely! Great fun, and I’d never have come up with that. Once you get SWAP and phase involved you can get some crazy stuff going on.

So, please read the Change log first and give it a go and get back to me.

[Spogg]

Tulamide shared some more ideas he would like to see, and even went to the trouble of making a flow diagram to illustrate what he had in mind.

I’ve implemented several of these in the linked zip file, and included his flow diagram and a small selection of clips for testing in the included player. This means you can see what I tried to follow and check it out without leaving FS. It’s not finished!

We decided it might be interesting for some of you guys to see how the project progresses so we’ll post here and you can make comments. I’m doing this with tulamide because he’s a real music creator and therefore knows what’s useful (unlike me!), so any changes proposed by others will be his final choice for inclusion.

At the end we hope to have a versatile delay that hopefully might appeal to other “producers”.

Anything I share should work properly and be usable as it is. But I must stress this is a work in progress.

@tulamide
No LFOs yet because I wanted to get the various modules and routing as you want first. Please read the Change log because there are some questions for you in there too. Just say what needs to be done next…

Here’s the zip for dev 33:

https://www.dropbox.com/s/kty2amz3kdlzy ... 3.zip?dl=0

[lalalandsynth]

@Tulamide

What do you use to make a flow diagram like that ?

[tulamide]

@Tulamide

What do you use to make a flow diagram like that ?

I used a versatile online solution. You don't even need an account. Instead you save your work to either file or browser and export it at any point to half a dozen of formats. You have access to a library of thousands and thousands of working blocks and you can change the page size at any point in time to whatever you like. Paid by through ads, but with a decent ad-blocker... well, that's your decision!
https://www.diagrameditor.com/

[tulamide]

For this project I'll go with 100% runtime-drawn (aka vector) graphics. The reason being simple. In Flowstone 4 we will be able to resize our plugin to any size we want. And runtime graphics are the only hassle-free solution.

With bitmaps you either have to live with low res, blurry graphics when displayed larger, or you have to waste lots of plugin data size and memory, holding larger copies to keep at least a bit of the sharpness.

With runtime graphics, you don't have an issue. On every redraw, all individual elements that compose a knob or slider or switch etc, are actually drawn, not taken from a bitmap and scaled to fit. The advantage is obvious: Because everything is based on grid steps, when resizing the grid step is increased/decreased, and all drawing fits to the new size automatically - with the same code! You only compose a button once, and it draws at any resolution in the same quality.

Here is an example with runtime graphics and inbetween one bitmap knob. Both are created only once. Then I increased the size.

gui_01.png (6.56 KiB) Viewed 18879 times

gui_02.png (22.43 KiB) Viewed 18879 times

There are a lot more advantages of course. Skinning your GUI? A breeze. Just change the colors or the dimensions, etc. No new bitmaps needed. You notice during development, that you made a mistake, and all your knobs need to be 2 pixel smaller? Good luck with bitmap strips. Runtime-graphics just get the new size input, and that's it.

A future-proof GUI needs to be runtime-drawn. And this GUI will also heavily rely on Windows 10. The market share of all older versions is marginable, while Win 10 has a share of almost 80%. Speaks volumes.

[MichaelBenjamin]

how does flowstones vector gfx heavily rely on win10?

[lalalandsynth]

Cool stuff Tulamide !

I have been looking into blending vectors and PNG's, so just using the png for shades and shadows .

There is a very nice plugin for both After Fx and illustrator to animate Rlottie Files.
In fact it would be amazing to be able to import Rlottie Files into FS, Rlottie/JSON files are just Vector animations , so you could use programs like Illustrator rather then using paint ruotines.

https://lottiefiles.com/featured

here is a wrapper for juce that works nicely.
https://forum.juce.com/t/rlottie-wrapper/35652

[tulamide]

Cool stuff Tulamide !

I have been looking into blending vectors and PNG's, so just using the png for shades and shadows .

There is a very nice plugin for both After Fx and illustrator to animate Rlottie Files.
In fact it would be amazing to be able to import Rlottie Files into FS, Rlottie/JSON files are just Vector animations , so you could use programs like Illustrator rather then using paint ruotines.

https://lottiefiles.com/featured

here is a wrapper for juce that works nicely.
https://forum.juce.com/t/rlottie-wrapper/35652

Lottie/Rlottie support has to be implemented on the source code layer, I'm afraid (or maybe as a dll, that you access via winlib, if timing is defined in the dll). The problem is that animations need a (reliable) timer, and that would mostly mean a seperate thread at least for those animations. This threading can only be implemented in the source code.

Regarding shades and shadows, you don't need bitmaps (well, you do, but only as seamless textures), because you can set both, brush and pen to use a texturebrush in Ruby. A simple disc with a gradient from shadowcolor to transparent would do the trick. You can then draw lines underneath the borders of your shape, and it will be a convincing soft shadow.

But yes, as of now, it's all to be handcrafted, I'm afraid. FS4 will offer to import svg files, but it just creates a bitmap and draws the svg into it, so that is of no help. And a Ruby svg interpreter is too much work than I would be willing to do. Probably several months. A guy with more stamina would need to do that, but I'm not sure, Trog ( ) would be willing to sacrifice his time for such a complex project!

[tulamide]

Here's a very simplistic, basic example of using shadow in runtime-drawn graphics. For this I didn't even use a texture, it is simply a PathGradient, set to black -> transparent

shadow_button.png (579 Bytes) Viewed 18781 times

Btw, for everyone reading here: Please don't confuse method and style. Just because my images used a specific style doesn't mean, runtime-drawn graphics could only produce this type of graphics. You can just as well use the oldschool style as Synthmaker used them 10 Years ago with bitmaps. Almost everything you use in pixel-based drawing apps to create your controls, does exist as drawing instructions for runtime graphics as well.

[Spogg]

I was wondering where we’re at with the Delay itself.

I’ve updated the design with LFOs and stuff but it would help me if you could give me some directions on the design so far. I asked 2 questions in the change log:

The SVF is mono 4 and I made it with common controls for left and right Freq, Res and type. Do you want Left and Right to have individual controls? Can Type be a common selector, so left and right are both LPF, HPF etc.?
The Drive module (which I’ve improved) has lo/hi cut controls on the input and output so do we really need an additional tone control “inside” the Drive?

Additionally:

Have I put the Drive mix control in the right place in the signal path?