Just out of curiosity, did you stress test the SSP with this? See how many concurrent vst modules could be brought up in the grid, etc?
I’m also wondering if your port is a straight implementation of the code from MI with the necessary nips and tucks to conform to the SSP, or if you uncut some corners that were done for the original platform (which is significantly weaker). IE: Did you give the algorithm more precision because you could, or is that portion of the port untouched?
Edit: Just because it isn’t always clear in forum posts, but I’m not asking any of this for any other reason than genuine curiosity. I’ve suspected based on my own work that you could run at least 8 modules of Rings before the CPU is bogged down, but my version never got finished. Since you’ve done such a good job here, i don’t see any real reason to finish it. But I’ve also often thought about expanding the MI algorithms as some shortcuts were taken that i think could be interesting on a more powerful platform like the SSP.
The code is as much ‘as is’ as possible, bare in mind it’s already been optimized for ARM, so we are getting a very good experience ( unlike when run on intel chips where that optimization is stripped eg vcvcrack!)
I’d not really want to change the code ( eg higher precision) as this would change the character of the module - if you do that you might as well write your own.
( vcvrack goes as far as down sampling to ensure it’s as close as possible and compatibility)
So the main process is one of compilation, building UI, and interfacing to the MI code ie replacing the code that interfaces with hardware to the new UI and ensuring parameters etc are scaled correctly.
No, I’ve not tried to run as many as possible.
I kind of think this is comparing apples n’ oranges.
I was amazed with axoloti how much performance you get from running ‘bare metal’ - so there’s a lot more that just chip performance in the equation.
At the end of the day, for me, the SSP is about what I can achieve - how do all the bits combine.
So, I have little interest in 10 rings - but rather can I run ( eg) - a few step sequencers, some lfos, midi input, a couple of rings, a clouds and wavetable oscillator, recording, using usb io - this has a ‘use’ for me.
I guess it’s easier to talk tech, but I had the impression ( I might be wrong) that this has done a bit of a disservice to the SSP on forums I’ve read.
I am not curious because I want to brag about how many vst’s the SSP can load up. However from a cost analyze of the SSP, it is easier to tell someone, well you could emulate 12 rings on your SSP, and then the price of the SSP makes more sense.
The unfortunate side affects of a discussion like this, is that it appears you are trying to bash other manufacturers. Which is not the case. There are many reasons you might still want a Rings module (i have one for example) , but because the SSP is such a blank slate, it’s value proposition isn’t always so readily apparent to folks.
I don’t disagree with your reasoning either on not being concerned with performance in that regard.
I’ll give it a whirl when I can, and I’ll let you know.
not really, its a completely different UX , its a trade off of HP vs hand-on experience (which is important in eurorack).
the price of the SSP is easy to justify on hardware and software development costs.
also functionality wise, look at the price of an ES-9, Disting EX, Mordax data, a decent fx unit - before long you are at SSP price levels.
even then its still not a 1-1 UX, its a trade/compromise of HP, Price, Flexibility.
I think this is where most ‘argue’ about multi-functional modules, not power - that undeniable, rather the UX.
this is an area I want to explore on the SSP, the idea of building a patch, but then having a ‘performance’ view - separating building a patch to ‘using it’. both via the SSP directly and also perhaps with other controllers.
anyway lots of ideas to explore
As of right now, the only way this could work, is building a synth inside of a vst for the platform or writing your own firmware (linux program). VSTs on the SSP just do not get anything other than 8 inputs, 8 outputs, and all of the hardware encoders and buttons to work with. Anything happening on the grid that can’t be passed to an input will be oblivious to it.
Now you just make a VST that would act as a control surface of sorts since all modules have inputs and outputs on the grid. You just drive values based on user activity and send them back out as outputs. Could be useful for sure, but also sort of limited. If you arrange your vst modules at the front of the grid, and just use bridges you could make switching between them all pretty quick as well.
I suppose that really could work. Could be a fun little rabbit hole.
I guess that just highlights how we see things differently.
I see being able to buy one module that can run an entire army of eurorack modules in one module very compelling. It means a 3U system can become a monster eurorack synth, for example.
In this way it makes the cost of entry to the grand quite affordable.
Of course there are so many roads to Rome, there is not right way to do any of it.
I’ve been having a lot of fun with this VST, I think it sounds lovely…
It’s got a number of modes,
the live ‘granular’ (mode 0) is the primary mode - and also the SSP has a great granular module already - Clouds does sound different (in a nice way)
however, there are a lot of fans of the ‘alternative’ modes,
I personally really love the ‘looping delay’, probably I like this a bit too much
ps: one nice thing about my SSP version is we can actually see the Pitch values in semitones, which Ive found it much more useable that the ‘real’ clouds modules… Ive been doing a lot of pitching shifting with the SSP, which I hardly ever did with the real clouds.
Ive also updated Rngs (1.0.1) ,
this incorporates a few changes under the covers due to things I was doing with Clouds,
also it fixes a bug @MOTOKO found with the module parameters not being persisted.
finally I added an input gain parameters, this is useful when using Rngs with external exciters (audio) which is a bit quieter.
thanks again to those that donated via https://ko-fi.com/thetechnobear.
not only is is useful for helping me to ‘fund my hobby’, but also it helps me feel that my work is appreciated and is being used by musicians - which is added motivation to do more
talking of motivation…
I’ve already started to thing about the next couple of vsts to be released.
not going to say what they are, build some anticipation…
one is fairly simple… but I believe will sound fantastic, and will provide a bit of variety in an important area,
it also uses some alternative dsp tech, which I’m hoping to build on in the future
the other, i think is super exciting, and I believe is exceeding useful and has been requested in the past,
however, its quite a bit more involved in that the vsts I’ve released so far - quite a bit more effort.
but it’ll be worth it…
both I’ve already done quite a bit of research, and done laid some groundwork on, just a matter of writing lots of code now
if you can afford to buy me a coffee to keep me awake to build these, or because you love the sounds of clouds - that’ll will be appreciated
anyway, have fun with Clouds… I personally love it.
playing back slices you should already be able to do with SAM by modulating START.
the issue I can see is selecting the correct value for START, you have to use fractions which is not very easy/intuitive (*)
but Im not sure there is a good solution for this…
cv are usually in the range of -1…1, so even if the SAM (or sample slicer) module took 32 (for 32nd slice)., things like the STE would not support it.
also throwing around large CV values like this, breaks the CV ideal of 'everything being equal’
i.e. you cannot send around 32v in Eurorack, everything is scaled to a norm , basically +/-10)
recording/managing slices.
ok, something like the Octatrack has a process of slicing routines - which are really cool. I love the OT for this.
this process, doesn’t add anything for ‘equal spaced’ slicing, for the SSP - due to above discussion.
where it would be useful, is where you manually slice audio, and they can be different lengths.
the only way you could make the new module use SAM, would be to get the user load the same wave file into the slicer module, as is loaded in the SAM… so that it knows its working on the same data.
there is no way to ‘enforce’ this, and if they got it wrong, it’d result in garbage.
that kind of ‘hacky’ module is not the kind of thing I’d want to implement…
so the only way for me to do it, would be to reimplement a SAM module, with added slicing capabilities, and that feels like a lot of work, for an improvement in workflow (*) and it also doesn’t solve/answer the CV range question… how can you use STE to sequence slices?
(*) this assumes CV values can be entered on things like STE accurately enough.
(**) you can already program these slice start values into STE, though its not very easy.
if i see how this is regulated on my Rossum Assimil8tor : 8 zones per sample can split, layed-out, spread over a 10V range - every CV in the range of -5 -> -4 selects the lowest zone, a trig triggers it and so forth
those 8 zones can be exploded or chopped again in 8 different start/end slices which can be triggered randomly, advance (on after another) etc - i’m sure smart heads like you can come up with some other means of ‘propulsion’
wow… the more I play and learn about the SSP, the more I love it…
so, I realised, actually sequencing slices is already possible and easy on the SSP
the ‘missing link’, I mentioned above, about easily sequencing/selecting a slice is not problematic.
whilst Ive been patching the STE before, I really just looked at the outputs , -1 to +1, I didn’t pay attention to the fact it was quantised step values (which can be changed up to 1024)
( Im still only a couple of weeks in, so some ‘subtleties’ are bound to be missed during the early days.)
so if you have a sample that is evenly sliced into 16 steps,
you simply set StLs (?) to 8, (which gives -/+ 8, so 16 values), and the SAM start to 0.500.
and viola, you can sequence slices by selecting steps on the STE.
so that means the ‘selecting a slice’ issue, is not an issue.
a ‘slicer’ module, could have two modes for selecting slices a v/oct (for external sequencing) and a linear (-/+1) mode - used in the same way we can use the STE+SAM.
of course, that ‘slicer’ module, would not have to use even slicing… it could have completely arbitary slice points… but slice number would be select as above (via linear or v/oct)
sure, no one is doubting its possible to write a complex sampler
but my ‘questions’ (now answered) were more how to integrate it into the existing SSP ecosystem…
(since the STE is not really using v/oct, though interestingly if you set it to StLs = 60, it should work as v/oct!)
so yeah, a slicer module is possible its just a ‘small matter of programming’ (ok, quite a lot of code!)
I’ll admit for me, I’m currently perfectly happy using the Octatrack for this, as it also provides a very convenient UI e.g. I can quickly sequence it… also it provides a ton of other functionality that would take years to implement on the SSP
but who knows that the future will bring… perhaps one morning, I’ll feel the urge to ‘give it a go’
for now, can’t wait to go use my new found STE knowledge for some other possibilities… first one to try is going to be sequencing the WTO x/y/z
Thanks for this, I tried some sample slicing a few weeks back when I first got my SSP and couldn’t get my head around some of the patching/settings. Going to give this a try later.
I simply meant that the wav file is arranged such that the slices are evenly over the wav file.
you can do this with most audio editors quite simply.
i’m not here for 'arguments’
rather just sharing observations , I made whilst playing with the SSP, that some may not have noticed, perhaps those newer to the SSP.
generally, I prefer focusing on this with a positive view, what can you do with the SSP, and how,
if as users we share these experiences/observations we can all make more of the platform.
UI is not finalized yet, eg outputs will be shown as stereo pairs ( functionally they already are, just I need to complete the stereo vumeter component)
I spy aux ins and outs too! This looks really interesting
I think something like this would really push the SSP into replacing a whole rack of modules territory even more than it does already!!
Great stuff
