More basic SSP questions

So, I’ve been working with my SSP off and on for a couple weeks now. I just finished building my first 16-sound drumkit, which is what I got my SSP for. It’s sounding pretty good so far. But in the process I’ve come up with some more questions.

  1. Is 64 a hard limit on the number of modules? It seems if I try to add #65, the SSP crashes.

  2. Is there a way to trigger an envelope to play through its attack and decay with the MTTR? I’d like to be able to trigger a sound with a slow swell, but it seems like the MTTR output is just a trigger, and as soon as the trigger ends, it goes to the release phase. Can I trigger PLTS to play through one wave cycle or something and use it as a one-shot LFO?

  3. Is there any way to map velocity to level of various sounds? My drum kit is completely velocity insensitive right now, because if you map the MTTR velocity to an amp input, you just get a click. Is it because the velocity is a momentary value while the amp expects a level over time? Can I use SWAT as a S&H to grab the velocity value or something? I suspect I just don’t understand how to use velocity.

  4. Is it possible to have the separate triggers from MTTR trigger separate envelopes without having multiple instances of the MTTR module? The ideal would probably be an octo-ENV module that I could use with MTTR and SAM (or other sources) to make multiple sounds without eating through my 64 modules so quickly.

(1) sounds like a bug, id assume limit was 128 (16x8).
ofc, that does not mean 64 or 128 is possible, as you may run out of cpu.

my random guess is that synthor somewhere has a limit of 64, but somewhere else assumes 128. but id need to go check the synthor code.

(2) Im not quite sure what you mean…
as far as MTTR is concerned, yes its just a trig…so indeed with a normal env, this would just be AR (or an AD) envelope… the exact behaviour depends on the env you use, rather than MTTR/trigs…
PLTS has a AD env iirc… so should work, but id need to test.

(3) MTTR has a velocity output… just use that?
note: the above does not take into account any bugs we previously talked about , refer to other post for that. … as ive already answered.

after the ‘fix’, the velocity will NOT be a momentary value, it will be retained until next trig.
this will help avoid the need for a S&H in some use-cases.
(and no, unfortunately, it being momentary was not the bug)

(4) sorry, I dont understand this at all…
MTTR can generate 8 trigs, you can send each to as many envs or whatever as you like.
if you need more than 8 trigs/notes… then you need another MTTR

Thanks for the quick response, Mark!

(1) I’m only at about 26% of CPU, so it’s not that. And it reboots regardless of what type of module I try to add. A limit of 128 would be fantastic. I have a lot more I want to add to this patch!

(2) Right, to go with MTTR I’d need a triggered AR envelope instead of the standard gated ADSR. But ENV only has a gated mode, right? Is there any other option? Using PLTS just for an envelope seems likely to be expensive in CPU.

(3) If I connect the velocity output of MTTR to an envelope, the sound becomes a short click. But I’m guessing the fix you mentioned will fix that. Thanks!

(4) is a little more complex, but it has to do with the fact that the SSP doesn’t distinguish between different instances of the same type of module when making connections.

Here’s an example. I’d like to make a patch where I have two drum sounds triggered by MIDI notes, one which creates a short sine wave ping and one a short noise burst. I follow these steps:

  1. Create an MTTR, set the MIDI channel and trigger notes, say trig 1 = 36, trig 2 = 38.
  2. Create an OUT for output.
  3. Create an ENV (call it env1) and an LFO. Set env1 with loop off, 0 attack, short release.
  4. Connect the MTTR to env1, connecting trigger A output to env1 gate input.
  5. Connect the env1 output to LFO amp input, and the LFO sine output to OUT input 1.
  6. Now when you send note 36, you’ll hear your sine ping.
  7. Create another ENV (call it env2) and an NOI. Set env2 with loop off, 0 attack, longer release.
  8. Connect the MTTR trigger B to env2 gate input. It will already be connected to ENV, so just connect trigger B to the ENV gate input.
  9. (connect the velocity A and B outputs of MTTR to the env amp inputs, because of the MTTR bug)
  10. Connect the env2 output to NOI amp input, and the NOI output to OUT input 1.

What you’d like now is that if you send note 36 you hear the sine, and if you send note 38 you hear the noise burst. But what happens is you hear both sounds for either note. And the reason is that the MTTR doesn’t know the difference between the two ENVs, env1 and env2, and when you connect them it just sends triggers A and B to both. Instead you have to disconnect MTTR from env2, create another MTTR (mttr2, say) and connect it to env2.

As a result, unless I have seriously misunderstood something, if you want to create 8 triggered sounds with envelopes, you need 8 instances of MTTR. This doesn’t come up with SAM (or I assume with DRUM) because it doesn’t need an external envelope.

The fundamental fix would be for the SSP OS to distinguish between multiple instances of a particular module, so that if you create 2 ENVs they are numbered, and when you make connections you can tell which one you’re connecting. (Of course, this would make the scrolling connections list issue even worse, but filtering it to only enabled inputs would probably fix that.)

A less radical fix would be an 8-env module (probably a triggered AR) to go with MTTR. If I start working on adding my own plugins, that’d probably be the first thing I try.

1 Like

(1) yeah, as I said CPU load , very much depends on patch/modules used.
its funny, I cannot remember hitting the 64 limit…but thinking about it, I probably have topped out at around 56 ish modules due to the way I tend to structure things :slight_smile:

(2) yeah, I dont use ENV much, as often Im using things with built in AD envs.
its funny though, I have memories, of really considering creating an AD module with a similar approach to OMOD… or even adding it to OMOD as a ‘feature’ (one shot) lfo.
but then obviously just forgot it… I do have a lot of ideas :laughing:

(3) indeed sounds like the bug, we discussed before.

(4) ok, hard to picture this without a diagram…
BUT from

this is why we have the BUS module!
basically, you send the signal to BUS, and from that output channel you can then distinguish different destinations…

using BUS is a vital part of SSP patching, once you go beyond simple patches.

Ive discussed the roles of BUS a lot on this forum, have a search… not only does it solve the problem but also for me, its an important organisational tool.

p.s. they may sound complicated, but once you get used to them… they are very simple, and have so many uses.

ah, id already I put a quick summary of what ive said on the wiki, in my tips n tricks section.

note: reading it, id point out its not ‘extensive’, there are many other ways to use BUS.
but once you have used it a couple of times, the other ways will ‘naturally’ come to you.
(notably, I think I talk about using one BUS module, but often I will use multiple, sometimes for ‘patching clarity’)

There’s so much here, I’d totally missed OMOD! I’ll have to experiment with it. Especially with CLKD – I’d like to have modulators that are reset every measure or couple of measures to create repeating variations in drum sounds etc

1 Like

Thanks for the BUS tips. I’d looked over your notes before but hadn’t tried it out in a patch yet. I just tried the simple drum patch I described above with BUS and it doesn’t really address the basic issue. I can add a single BUS module, send the two MTTR trigs to BUS 1 and BUS 2, and then connect the BUS 1 and 2 outs to env1 and env2.

But if I use the same BUS module for both ENVs, then both triggers still gate both ENVs. I still need a separate BUS for each ENV to keep the triggers distinct. However, BUS presumably saves some CPU, and it allows me to have all my midi channels and triggers defined in one place.

1 Like

MTTR trig A, B → BUS (1) in 1, in 2

BUS(2) out 1-> ENV(1) gate
BUS(3) out 2-> ENV(2) gate

this should work , no?

as I mentioned there are different ways to use BUS depending on what you are trying to achieve.
really the key is, you are using BUS to create separate modules, with different connections.
(but they ‘kind of’ internally act like one module… if you get what I mean)

BUS is pretty low cost, its basically just copying audio buffers, which is a pretty low cost operation.
this is why, im happy to use it, even when its just for ‘organising’ my patches better.

BUS can potentially introduce a one sample buffer delay.
though, unfortunately, this is not predicable on SSP due to the way modules processing order (and threading) is handled (and is seen in other circumstances beyond BUS too)

Oh yes, that definitely works. My point was that if I’m trying to save module count (since I’m hitting the module limit before I hit the CPU limit) it doesn’t really help. If you want to trigger 8 ENVs off an MTTR, you can do it with 8 MTTRs and 8 ENVs or 1 MTTR, 8 ENVs, and 9 BUSes. But you can’t do it with just 1 MTTR and 8 ENVs, or that plus 2 BUSes.

Of course, you can get a full 16-sound drum kit with basically 2 MTTRs and 2 SAMs, but the fun is in synthesizing weirder sounds and tweaking them on the fly :slight_smile:

oh for sure, introducing BUSs is going to increase the module count… but its a solution to the issue at hand, albeit exacerbating a different issue :wink:

I should say the above was for clarity, you can actually do with 2 BUS

MTTR trig A, B → BUS (1) in 1, in 2
BUS(1) out 1-> ENV(1) gate
BUS(2) out 2-> ENV(2) gate

i.e. the first BUS can be uses as an output.
but yeah, it doesn’t scale well for this use-case.

as for module count…
there are lots of different tricks, all of which (ofc) are highly use-case dependent.

off-hand, I can think of a few things that might help:

  • many modules have built-in VCA, so often you will not need a VCA
  • use different modulation source, ie… don’t use 2 ENV, use an ENV + something else
  • CART can be a useful 2 (complex) modulation sources.
  • OMOD, sync’d modulation can be useful for rhythmic elements.

CART and OMOD are both extremely flexible. frankly, even I forget whats there… as basically, I add features, based on use-case I come up with whilst coding.

OMOD has some interesting ‘clock’ behaviour. also because it has a reset input, it can kind of be used like an AD envelope. also remember its got an EOC output, which can be used for quite a few creative uses.

and, I could probably talk for an hour just on possibilities with CART
( see Rene mk1 videos for a bit of inspiration)

the other one to watch out for is CLKD, whilst it appears to just be a simple clock divider (its primary use-case) it has some very interesting behaviour when it comes to clock input signals… esp. if you start sending it irregular pulses. (theres some ‘hints’ of this on the wiki page)


overall with my (technobear) modules, I try to design them so that the simple use-cases are easy, and work out of the box, but I have a few little twists in there. I try to think how we might combine things in different ways to create something different.
as, frankly, thats how I approach modular, both SSP patching and Eurorack. ( * )

obviously there are some limits here,
adding too many inputs, outputs and parameters can create quite a bit of extra complexity.
also, often Im trying to limit the cpu load in the simple use-case example.

so this is why sometimes, Id prefer to create an alternative module, that might ‘appear’ similar but has a different focus - esp. as an extra module, doesn’t ‘cost’ the user more as it would in hardware :wink:

e.g.
one could argue OMOD could have 8 trig inputs, that were normal off one primary input, so giving 8 independent lfo/envs. but thats counter to its primary focus which was 8 mods from one source (usually a clock)

the slight ‘issue’ here, is whilst I could ‘knock’ these variations fairly quickly, Ive just not got around too it, as Im simply busy on other projects.
(that and whenever I create a new module, I usually get sidetracked add new things!)

anyway, I will do some more in this area at some point, as Im a big fan of modulation… the more the merrier. its what makes modular so unique for me.

BUT… Ive got a few (bigger) projects Im working on at the moment, including an SSP one, that are unfortunately, taking quite a bit longer than Id hoped. though they are pretty exciting.


( * ) I will say, this is a bit of a personal approach.
I know many (in eurorack generally) prefer one complex module with lots of different options, rather than the idea of using multiple modules…
and I do understand this, esp when you are doing polyphonic voices where you have to have duplicates, its easier to duplicate one module rather that 4 (for each voice)

ok, I had a quick(!) look at synthor code.
I cannot go into details, but indeed 64 should be the limit.

I think the idea of the 16x8 slots, is more to allow some space for organisation.
this kind of makes sense if you consider there are 2 x 8 on the screen at once. so you could think of this as 8 x (2x8) , rather than 16x8 (which is honestly, how id viewed it!)

ok, thats probably not clear… but I know what I mean :laughing:
just consider it allows a bit of room to organise your patch a little, so its a little clearer.

could it be increased?
I think this historically this would have been problematic, due to memory constraints.
I know some changes were made in the last release, which alleviate this somewhat, however, id need to look carefully at the details to see to what extent this is possible.
but, it’d still be a trade-off with memory available for other uses used by users (like samples).

overall, this is something that you’d have to discuss with Bert, as these kind of trade-offs in synthor are up to him.

anyway, the 64 module limit is not a bug. rather the bug, is a UI one, allowing you to create that 65th. I wanted to clarify this, as above I kind of implied I thought the bug was not to allow 128 modules.

note: I cannot discuss the details of the implementation (or implications) (NDA). so the above is general, and I cannot go into why the above is the case etc. you’d need to refer to Bert for details.