CLDS : Texture synthesizer, by TheTechnobear

Clds : Texture synthesizer

clds - an implementation of Mutable Instrument Clouds for the Percussa SSP.

Download : here

Documentation : here

Developer: TheTechnobear

I develop these plugins for free, please consider supporting my efforts with a donation.


my holiday begins next weekend so i plan to have much fun with these new VSTs

thanks for you efforts, much appreciated

1 Like

Thank you very much for your development. I can’t wait to test it out.:slightly_smiling_face:


congrats, great work


I installed Clds and did various tests. It’s very impressive. Thank you again for developing it.

Excuse me, but may I ask you a question?

Now, the Clds are great, but like other Clouds clones, do you have any plans to add more CV inputs for the Clds? (e.g. Monsoon, Typhoon)

With the addition of CV inputs such as Feedback, Reverb, Pan, more sound experiments may be possible.

Then, I’d appreciate it if you could give me a reply.



1 Like

the VST SSP host currently only supports 8 in/ 8 out - this is why we have limited CV inputs.
(as you can see, Ive already broken out the blend parameters for the UI)

I already mentioned this in the ‘general usage’ of the OP :wink:

I’ve asked @bert if this can be increased - at that point I will add more CV inputs.

related, I’ve also asked if the inputs/outputs can be named (vsts support this), like they are on other SSP modules - however, thats a ‘deeper’ problem - since it means each VST will look a bit ‘different’.
but hopefully a solution can be found.

note: before anyone asks :wink:
I’ve no intention at this time of supporting things like the parasites firmware, doing so could be quite a bit of effort, and also doesn’t really fit into what Im doing with the MI stuff…


Oh, I didn’t check this part. I’m sorry. :pray:

Yes, I also think adding CV input is not easy because the default value of the vst module is 8 in / 8 out.

And I also wish the VST module had an input/output name.:slightly_smiling_face:

Anyway, I’m relieved that you’ve already planned it and I’ll have to wait for the update of the VST module.

Thank you for your detailed answer.

yeah, best way to think about this is…

the SSP VST module is what interacts with other SSP modules.

this SSP module ‘contains’ (aka hosts) actual VSTs - this is what you do when on the P screen you ‘assign’ a VST to that module - you are placing it inside that SSP VST module. that VST module then passed information from the rest of the SSP to/from the VST.

so… whilst I can already create a VST with as many input/outputs as I wish…
the issue is the SSP VST module, will only ever expose the first 8 to the rest of the SSP system.

it’s actually pretty simple for me in the VST to support more CV when they are available.
though as above, I ‘fear’ without proper naming on the network screen, its going to get challenging for users to know which inputs do which.

anyway… this is under discussion, so hopefully in the future this can be improved.
I know Bert is also keen that VST have ‘parity’ with SSP modules.

in my mind this is the natural course of development… only when VSTs started to get used ‘in anger’ would it become clear what works, and what might need improvement esp. since there are obviously so many other things on the ‘wish list’ for the SSP.

I’ll obviously ‘track’ these developments, and make use of them as they happen :slight_smile:


I will add more I/O for the VST module in the next version of the SDK / synthor update and will look into a solution for the I/O channel names.


Thanks for the continued sharing. More ground roasted beans and hot water coming your way…


Thanks to your explanation, I have a better understanding of the relationship between SSP and VST module. I hope that SSP will expand further with your development. :slightly_smiling_face:


Thank you very much, Bert! I’m looking forward to the next update for SSP. :pray:


release 1.2.0

new version of clds for latest SDK version - see top post for changes included.


release 1.2.1 small fix, texture was not being persisted when saving preset

1 Like

as mentioned on my dev blog , this is a work in progress protoype of clds… and the way I plan to take my other plugins UIs.

on ko-fi ( public post) my blog post details my current thinking, and why it is as it is… what I like, what i don’t :slight_smile:

Im posting here… as I’d like all ssp users ideas on if this works, and how it could be improved.
(and fear perhaps some don’t read the dev blog above, as its tends to be technical)

note: please read the ko-fi post, as it details why its like it is… this is about building a more generic UI, rather than ideas on how i could create a fancy ui specific to clouds (e.g. depicting grain bursts)

1 Like

Excellent stuff here.

Only one minor bit of feedback— it might make sense to mimic the front panel control placement of the original module. That advice aside, the controls in the mockup do seem to be logically placed based on functional proximity.

Back to my point—

Barring the inclusion of virtual knobs (or bars) showing the precise full scale value of each parameter— placing the location of each control where it resides on the original panel may help reduce cognitive load for users already comfortable with the original hardware.

This also brings an intrinsic benefit of training non-hardware Clouds users where precisely they can find the controls on the front panel should they ever encounter the hardware in the wild.

Again, minor point here. Keep up the great work!

1 Like