PLTS : Macro Oscillator, by TheTechnobear

Plts : macro oscillator

plts - a very versatile oscillator based on Mutable Instrument Plaits

Download : here

Documentation : here

Developer: TheTechnobear

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


awesome :slight_smile: thanks for your hard work!

1 Like

Thank you very much, Mark - Plts sounds just great!


Thanks so much for your hard work! Just a quick question and i may be doing something wrong… Is the Plaits display meant to update when you get changes from CV? Right now i can hear the changes but the display does not seem to reflect them.



The parameter values don’t update within the module pages, but if you switch to the Network Page, you can see actual values of input and output parameters reflected in the scopes. Highlight the parameter you’re interested in.

1 Like

yeah as @titaanzink says, its intentional.

the display value is the ‘base’, and the cv is an offset.
this is true of all modules - like a real physical module

the issue with displaying the modulated value, is it makes it pretty difficult to adjust when its being modulated, since the value is constantly changing.
… i guess as some point, i could do something like subltly overlay the modulating value, but personally , I dont find it adds much to the experience.

No worries. Thanks again for the great work. It was more a curiosity thing.

1 Like

In the demo of the New firmware 2.0 you play PLTS with an MPE controller. can the PLTS create instances of itself, or did you have 8 PLTS in the patch?

its multiple instances of PLTS.

there is no polyphony concept in synthor (or frankly many modular environments, though this is starting to change)

that said, I’ve been considering creating a polyphonic PLTS module, since the new firmware fixes the issue with my ‘direct midi’ implementation.

so the fundamental issue is… there is no poly cables, and synthor cannot send midi to a 3rd party module.

the way this has to work is that my modules would directly take midi input (as used by my learn etc), and then internally voice based on that midi.
so its very much a self contained module… where I need to implement polyphony/mpe etc we are starting to see this in eurorack which have midi trs jacks, basically its a full synth in a module.

so its not trivial, but I think could be useful , a quick way to get a polyphonic voice - in a similar way to the my new DRUM module gives a quick way to get some percussion.

I’ve some open points in my head about this, that im still considering

a) dedicated poly engine
I might actually just use the plts code as a starting point, but refine it for polyphonic use… ie. its something slightly different, and wouldn’t have the plts engines that ‘dont make sense’

b) modulation matrix
for MPE in particular, id need some kind of per voice modulation, and that means having some kind of modulation matrix… in fairness, could probably be linked to PLTS existing ‘mod parameters’

c) poly use without midi
this one may come later, but it be nice to be able to drive this module from a sequencer… but Id need to think how best to do this.
simple option is to have not just v/oct + gate, but something like v/oct 1-4, gate 1-4 but its a bit messy ( in number of inputs)
I did think about ‘interval’ as inputs, so having chord support - but I think it would be more ‘modular’ to have that chord voicing as a separate module.
its possible this separate module approach could be how I handle the midi side too…ie. a poly midi module with (e.g. 8 outputs), but again concerned about number of outputs this yields.

d) individual voice outs
i guess, id have a sum out, which would be the main output, but perhaps individual voice outs, for flexibility.

anyway, its something already under consideration, as it kind of fits my goal of having some modules which means its super quick to use the SSP in a particular role as a standalone instrument (see my ‘how do you use the SSP’ topic for where Im heading)

btw: i should say using multiple PLTS as I did for the ‘demo’ is entirely viable, and frankly, the dsp load would be pretty much the same in either approach.
the separate PLTS has the advantage of flexibility, a poly PLTS would be mainly just convenience.

I Think I saw someone else experiencing PLTS freeze, I can second that…

STE-PLTS… fast or slow…gate sequence change the “model” backwards and forwards a few time while the sequence is running and it will trigger the error…

Most the time the first “models” upto and incl particle stops working and the rest keeps working…

I thought the other issues was CLDS - no?
( can’t find it now, you have a link?)

I’ve seen this in previous firmware / release - so don’t think this is a new issue.
it’s hard to track down as it doesn’t happen on macOS, where it’s easier to debug - I’ve already reviewed the code a few times … and nothing jumps out as being wrong … and the same bits of code work most of the time… I believe it’s some odd state in the MI code, but as I say, can’t get a proper handle on it.

ok… Will just turn off seq before changing model… that will work…

yeah. its interesting that firing a trig is causing it… I felt before, it was pretty random i.e. even if a note was not playing.

Im still a bit confused whats going on, as when I look at the MI code, basically its constantly checking (and potentially changing the engine), regardless of triggering or not… but it also checks the value is valid, and will ‘reset’ the engine if necessary.

the only thing, that I think could be causing this is a value that is not ‘valid’ for a particular engine , but there is no evidence of this… so its a little odd…

Yes and weird it only crashes half the module :-/.note: never experienced it with RINGS…

I’m trying out sequencing it such that it changes state in between triggers… so triggering the preset in the VOST with the STE : L2 with 10 increments while I trigger the instrument and setting pitch with the L1… so changing preset and settings in between notes… so it gives it a bit of time… seems to work ok…

Thanks for you looking into it. I truely appreciate your help to the community

I’m still experimenting with VOST…
What a module that is… it also works great as a sequencer… I use it to change settings in VST via the midi out on the pc… More than anything modules like these these have me sit in front of the ssp for hours experimenting… it’s like meditation… ohh and the CLKD is a welcome member… my next deep dive will be logic… I will write up a more detailed list on the appropriate forum tread once I have done a bit more exploration on all the new modules… thanks again… and good idea about the way you drop all the new modules… it’s always Christmas like that :slight_smile:

yeah,I’ll experiment with PLTS a bit, see if I can find some kind of pattern.
(perhaps, I can create a debug version and get a stack trace that sheds light… but I dont think it will)

can you confirm if you are modulating model? … though that should not matter anyway.
my assumption is, you are just triggering plts with cv/gate, and then ‘manually’ changing model via the UI.

VOST, indeed, theres a lot of use-cases … sequencing is a fun one.
Im thinking of changing VOST to 16 layers (from 10), the reason I choose 10, was the voltages to select layers were more obvious.
have you tried VOST with MSW8? that is a different kind of sequencer!
(again, Ive been thinking of creating a 16 channel MSW)

basically, with MSW8, one layer becomes a sequence using MSW to move between the values,
and then layers becomes patterns…
(or you can invert this, so one layer = 8 patterns, and layers are the steps)
basically VOST + MSW8 (one or more :wink: ) allow you treat the voltages as a grid.
combine these with SHQ, and you have a fun generative melody maker.

oh… and don’t forget VOST can take CV in, and be used more like an attenuverter, this yields a whole new set of possibilities… e.g VOST → VOST :wink:

thats the thing about these kind of modules, the power is in the flexibility… they don’t have a ‘fixed’ purpose.

ok, Ive just PLTS being sequenced and changing the engine… and I cannot get it to crash.
even at super fast sequences, I can sit there twiddling with the engine parameter, back n’ forth over whole range and it works fine.

so Id need to see your patch, post it here and I can take a look…
perhaps you are sending something odd in your patch, or one of the modules plts is connected to is ‘acting up’…

(I tried using the demo patch I showed on YouTube the other day, and sped it up… so thats using my new modules… but using the same version of (beta) PLTS I released here)

Hmmm strange… I do find that it takes a bit… 1-2 min before it gets “tired” of playing the models upto particle…

i will remount the new core… i have had once or twice where the ssp failed to mount the sd… it may be a problem on my side then…after that process i will recreate the patch and post it if it still exist… just to make sure i dont copmplain about an issue that does not exist :slight_smile:

yeah, I need a preset that does it consistently… I tried for a while, doing all sorts of things, and had no issue… besides, I cannot debug an issue unless the steps for the issue are not complete.

  • load preset
  • set timbre to x
  • set model to y

the issue is, even if I can get it to crash, that’ll very likely tell me nothing useful, so it’s important to know the setup and steps, and be able to reproduce - to start getting hints at what the likely issue is.
unfortunately, as I said, at start… its likely the issue in in the MI code… and how this ‘operates’ on the SSP, rather than any code I wrote - so I need some kind of ‘starting point’, as Ive already checked the likely problematic areas, and that revealed nothing.

note: I assume you are running at 48khz on the SSP? (I do not test/support any other sample rate)

a side note…
in case people are wondering, why does it not crash as hardware, or in vcvrack, if its not my code?

hardware - as a very different interface, and can only run ONE instance, its not loading as a ‘module’ into any kind of host… besides, surrounding libraries (e.g. memory management are very different)

vcvrack - does not use the optimised arm based code, due to needing to run on Intel machines, so it uses a so called ‘test’ mode which is nowhere need as efficient… of course that does not matter on a desktop since the cpu is so much more powerful than the hardware STM32F4/7 chips used by MI.
this is also why, PLTS will not crash on my macOS test/development setup - as it’s similarly using this ‘test’ mode.

… so theres, some unique aspects about running PLTS on something like the SSP, which could trigger issues in the MI code (as it was NOT designed for this use-case)

btw: the same is true for any of my MI based modules, though if we have issues, is highly dependent on what the MI code is doing.

1 Like

I re mounted the new synhtor and now i cant get it to crash :)…

1 Like

odd… I’d doubt something like that would cause the issue, unless there was some kind of corrupted preset… but keep an eye out.
not much I can do , if you have a preset in the future that exhibits the issue, then post it and I can see if I can replicated.