Percussa Home / Shop / Contact /

TheTechnobear's SSP/XMX development

SSP SDK
#324

do you get it in the AUX when all widths are set to zero?

Ive notice some artefacts…
but in my testing it seemed the same on SSP, as in max, and when run as vst n my Mac.
that said, my testing is somewhat different due to various constraints.

as mentioned on the GRA4/LOOP topic, this is all really exploratory stuff…
really to allow users to get involved, e.g. with testing, and to see part of the journey.

unlike my normal modules, these are very in the dev process,
this is why I labelled it exploratory, a peak behind the curtains.

as Ive talked about before here, Im not even sure where this rnbo stuff is going to end up (if at all) in my toolbox, Im mainly using it for prototyping , trying ideas outs… so very much exploration.
also this fft stuff, esp in this context, is also reasonably new to me.
and then rnbo is also new, no doubt with bugs in it.

so, perhaps this is my mistake…
too many factors, which make it all a bit too ‘bleeding edge’

of course I do understand people are busy, so perhaps the expectations are higher ( * ) … they want to just play with stuff that works. so, perhaps it’s better, I release when/if it’s further along the development path.
I’ll consider this over the holidays, as I certainly dont want people to ‘get frustrated’ !

–

( * )
hmm, counter example…
Id say I also consider the rnbo template also exploratory/alpha, and yet I think @Handsonicsuki has done some great things with that, and I believe is enjoying it.
though, thats not a module, so again, different expectations.

but, this politicking/expectation management , concerns me a bit…
one of the reasons I do ko-fi, was just to allow people to support me , just for my contributions to the community… but without creating ‘expectations’ which are hard to fulfill as this is a hobby for me.
its a concern, that Im now getting into ‘expectation management’, as its kind of going down the route of EAP being about ‘product delivery’ , which its not :frowning:
definitely needs some musing over …

#325

just to confirm, this clicking… I’ve doubled checked I get also on the Mac, both in VST and in Max.
best test case I have is , sine wave 440hz () , bin=0, width =1
() this is easy to do in max, but also with plts using fm model, to get single sine wave

Im probably going to need to write some test patches in max to see whats going on.
either its an over simplification on my part/limitation on fft… or possibly a bug in rnbo fft/ifft.
all part of the exploration stage…

not sure when I’ll get time, given holidays are on us … so im already ‘sneaking out’ to do these test :laughing:

happy holidays, ho ho ho :santa:

#326

I think that we are not buying those as a commercial plugin and those are in a exploration stage now, so it seems odd to feel frustrate by seeking perfection.

Looking at the plug-ins in the process of exploration is very useful for me to understand what that can do with the RNBO template and how it can be extended with C++.

@thetechnobear 's RNBO template is really a game changer for me.
I have already confirmed that some of the functional parts I wanted to make work, which will take a time, but I can build the system what I want by “myself”.
It’s really exciting.

2 Likes
#327

sure, but I don’t think we are talking requiring ‘perfection’ here…

Id say, theres more a line
Development → Interesting → Usable → Nice → Perfection

some where around ‘interesting’ for some, is where it could be frustrating for other, as they feel Im ‘wasting’ there time… which is understandable.

anyway, skived of other duties for an hour or so… :see_no_evil:

created some test patches etc, to dig deeper, do a bit more research…

what Ive found was:
result are identical in Max/MSP , so the noise is not an issue with SSP/RNBO etc.

it is as I suspected, an artefact of the fft->ifft process.
as mentioned im using a single fft->ifft chain… this creates artefacts, thats just what it does !

this is why we’d prefer to use overlapping ffts, but its at the expense of processing.

ok, none of this is new to me …

that said, I did also play with some different windows.
so even for a single fft/ifft chain, Its now less noisy.
basically, its more of a warbling sound, than the glitchy/digial clock type noise before.

so Ive updated SFLT and uploaded it (same filename etc)

note: you might still get some noise… esp at higher amplitudes, but its sounds a bit nicer I think.
so hopefully further along the interesting → usable line :laughing:

tip: you might want to consider following SFLT with a filter, and also a bit of drive… this add bit the sound after this kind of processing, which can flatten it a bit.

way forward?
not sure…I did experiment, and for sure, overlapping with 2 fft/ifft improves it (still not 100%) but its going to double the cpu load… using 4 overlapping fft/ifft works even better… no prizes for guessing what that does.
perhaps reduce the number of fft bins (I’ve already talked about disadvantages of that)

as mentioned early on with frequency domain exploration… none of this is cheap, in computational terms.
so its a matter of me finding sweet spots… cpu load vs usability.
this is all ‘part of the process’ - this is the nature of all computing… the SSP is powerful, but its not an 8 core desktop cpu.

but of course… I know this is probably only interesting to those doing development,
I get its probably tedious if you just wanna use it.
… its, frankly, why most devs don’t frequent forums much, not many are interested in the process.

#328

TTB,

I love the work you are doing and fully appreciate that you are releasing modules in different stages of refinement. To be clear, I didn’t know what to expect and I just thought that something was wrong with my device based on the results. (And other issues) Sounds like maybe this is how the module is designed to perform? That’s totally fine if that’s the case. Let’s keep going!

Example patches might be helpful too.

I tried the FFT into 8 oscillators and it was pretty wild. Definitely going to explore more.

This is an interesting breakdown, the SSP on the whole feels all over this spectrum. That’s just what this playground is like I guess. Many of my frustrations are just with the interface and the bugs I reported a while ago. No response, was very telling. /rant

But back to the matter at hand. I apologize for not couching my previous post properly. I am very happy with the inspiring work you are doing and I didn’t intend on discouraging or calling into question the experimental nature of it. Operator error and expected performance is totally fine with me. Please don’t stop.

1 Like
#329

feedback FFT controlling sample pitch, start, and length. crazy…

2 Likes
#330

no worries, as I say, a lot of this expectations… and perhaps, I was ‘releasing’ a bit to early to actually be useful :slight_smile: … also , as my follow up posts shows, I kind of have a feeling of the limitations of these things (and the trade-offs I’m making, and why), that of course, others who just get to use the module, don’t have.

… unfortunately, I think one of the hardest parts for everyone with the SSP, is knowing exactly where it fits. for a eurorack module its powerful (computationally, IO etc) , but its no desktop/laptop.
this means, everyone has very different idea of what role the SSP should take… with different expectations.
Im 100% sure, my ideas on this are pretty different to others (though I have articulated these in my YT videos on the SSP).

but all this feeds into development…
deciding on which modules are suitable for development on the SSP, and their boundaries, their tradeoffs / compromises… takes a bit of exploration, a bit of wandering around.
and thats kind of whats going on here…

that, and of course, like any developer, I just love playing with new ideas… and sometimes thats more fun that finishing stuff :wink: (not unlike jamming/improvising vs finishing a track!)

talking of which, Ive just started another crazy idea for the SSP… nothing to do with rnbo/ffts.
and its a bit out there… its too early to discuss, and may not work,
but if it does… its going to be wild!

2 Likes
#331

well I’m stoked… it took a lot of effort , but the proof of concepts works !
a long way off till its ready though …
but, when it is, it will opens new doors… potentially, making the SSP attractive to a new type of musician.
… and with that cryptic tease, im off :clown_face:

3 Likes
#332

Way to ruin my sleep during the holidays :laughing:

3 Likes
#333

Spending a lot of fun time with the GRA4 and CLKD modules, and some FFT magic feedback parameter control. Couple questions and thoughts:

  1. Can the CLKD have an input to control the Clk Div? This would be a neat way to create cv controlled clock divided bursts / subdivisions. Similarly to have control over the Div A … Div H parameters with cv would give a whole other dimension to this module.

  2. What does the “Size” parameter do in the GRA4 module? If I turn this a few times it seems to zero out the waveform and the sample will stop playing until I reload it. Is it erasing the end of the loaded sample from memory?

  3. If I let too many trigs come in, either real fast or many buildup over time, the sample playback will overload. It’s like the trigs start overflowing. I’m somehow giving it too many requests to play a grain, since maybe grains seem pretty wide and aren’t done playing when a new one is requested. I suppose this might be expected behavior, but it can make it dangerous to leave things triggering. Not sure how to get very predictable sample repetition.

Anyway, super great instrument.
&e

#334
  1. CLKD CV clk div
    I don’t think this would work as you intend… i.e. to create things like fills/rachets.
    the issue is you would loose sync, and be unable to return back to the original ‘tempo’
    because the return would have to be precisely sync’d on the ‘1’.
    e.g. imagine a simple 4/4 beat, and you want to do a 1/32 ratchet on last beat,
    this would need precise timing, and CLKd has no concept of the original/intended clock to do this.

this is why we have things like burst modules, that don’t change the original clock, rather they just. use it as a source…, so can you can easily sync back to it.

  1. GRA4 Size (and Loop Size)
    is the memory buffer size, as mentioned in the docs, you should not really be changing this… its really ‘how much resouce/memory’ do I want to give to this module.
    (if I hardcoded this, we’d be trying to decide between ability to have more loops or long playback times)
    so you want to have this as small as possible :wink:

if you want to loop/use a smaller area you should use start/end.
its only a convenience function that changing size does not entirely wipe the buffer - it used to :wink:

  1. Grab 4 trigs
    I’d need to test/review this…
    gra4 is based on the granulator~ rnbo object.
    it has a fixed number of grains, it defaults to 32, but I think I might have changed it to 16?

I would (expect, but need to check) max will ‘re-trig’ a grain when it reaches this number.
but I guess they could choose to ignore trig, need to check.
either way, it should not exceed this number.

I did some testing, but if its overloading cpu, all be can do is deduce max grains.
(basically a grain is like an oscillator, so to many is trouble)

as for life time, this will be controlled by length (or did I swap size/len around in gra4? iirc, this goes from 0…1, so its a % of buffer size.
I can’t remember if Ive set this to ‘wrap’ if it hits buffer end, or stop.

anyway… no it should not be dangerous to have to many triggers, though they will consume cpu, up to the point of ‘max grains’… and of course cpu, is shared with all other modules :wink:
of course, this is assumng granulator~ is doing it’s job properly/as expected.

overall needs some testing, if you look at the docs I linked above, you’ll see the documentation is woeful, so testing is the only way to check for inaccuracy, or if Im making incorrect assumptions.

the best way to test, is to use a large sample, and be very particularly/precise when triggering.
this way you can do everything in ‘slow motion’ (because grains can be longer)
anyway, needs a bit of time.

#335

Thank you for these. Regarding the clock, I understand the timing issue if i were using this in the manner you outline. I’m not using clock this way however. For me it is a source of trigger seads for gra4. In this case manually flipping to different clock divisions gives great a little burst. Same with changing the individual divisions for each clock channel. Generally I am running the clock at 10 to 30 bpm and then bursting as described above. Having the CV control would open up lots of fun possibilities.

#336

yeah but what works for one persons ‘odd use-case’,
though, others would argue its bug ! (because they’d rightly expect clocks to stay in sync) (*)

I think this would likely be better in a burst module, like the one @Handsonicsuki
or perhaps one modelled a bit closer to Befaco’s Burst.

I think this would also be generally more useful unrelated to clocks…
e.g Id quite like to link bursts to a sequencer (CART).
I was also thinking the other days about some kind of Euclid module, again… something it be useful to create burst off of their trigs.
(hmmm, could also be handy to have a trig → gate function!)

of course, we all have different ideas… based on our imagined use-cases.
but as stated previously, my preference, is module are blocks, so we break functionality up into blocks.

(*) that said, I do understand why many would say make everything ‘cv-able’, unfortunately, theres technical cost (and side effects/complexity) to this, so as part of the design I do tend to pick n’ choose, its part of the compromise… and tend to ‘err’ on the side of less, esp. during initial development…
(one rule of dev is… its alot easier/more acceptable to add things later, than try to take something away later :wink: )

#337

Sure. Why it sounds cool in a clock is because they are subdivisions and not just a bunch of chaotic busy triggers. Anyway., I’m just saying it would be cool, if. I’m not saying make everything CV, just the things that lend themselves to new ways of thinking. That’s what makes a basic module into something inspiring. Thanks again!

#338

Sure, I understand, I’ll think about it.

burst does not need to be chaotic triggers…

befaco burst (which is likely the one id model after… since I generally like befaco design :wink: )
can be clocked, and also you specify distribution… so can be even, or lin/exp.
and it can have probability or not…

this is the reason I look at other (eurorack) modules for inspiration… its a way of picking up on a thought process…and frankly, most hardware devs, will go thru a design phase with some ‘key users’ who help them hone out whats useful.

as for now… theres may different ways to achieve what you are talking about, that are already possible.
the beauty of modular, is we can always come up with different ways…
(and thats why, Ive spent some time working on ‘simple modules’ that allow combinations)

first… with CLKd its worth remember it doesn’t just take clocks !

you can send in wonky and ever changing trigs (clk) (even at audio rate!)
so there is no reason you could not speed up the underlying clock to get your rapid bursts.

(note: you’ll likely want to use divisions only not multiplication… also check out behaviour of trig sync… its important here!)

so you can then do thing like combine clocks with logic
CART/OMOD/LFO->SHQ/value → CLKD/clk
CART/CLKD/LOGIC ->SHQ/trig

or use multiple clkd, in various different combination…

CLKD (fast) → MSW8 (in1)
CLKD (normal) ->MSW8 (in2)
CART ->MSW8 (sw)

CLKD(fast), CLKD(slow) ->LOGIC (and/or)
CART->CLKD(fast) run/or clk

#339

another idea… (and one that shows not even I remember what Ive created sometimes :laughing: )
use OMOD… omod is clockable, and allows you to modulate the frequency of the sub modulators.

again, its a bit different from how above Id use CLKd where basically I use it more as a traditional clock divider… but in the case of creating bursts thats kind of inevitable ( * )

again, you’d feed this into a logic module then AND this with your ‘gate’ for the GRA4

what I like about my approaches listed is they can all properly sync’d to other clocks (or not)

(*) a divider can only ever create something slower… and an multiplier is based on ‘estimation’ based on the past.
amusing fact, this really confuses terminology when you developer clocks n’ dividers…
if you think musical … then you divide a bar into (say) 4 beats.
but actually, thats a multiplication … take 1 trig (bar) , and create 4 trigs. i.e. 1 trig = 1 * 4 (mult)

in non-digital modular (so analog), Id guess, you probably want your master clock as fast a possible, and then only use dividers…
and still today, this is also the most ‘accurate’ way to do things, if you want you want to use irregular clocks.

(since division only ever needs 1 trig, whereas multiplication by definition, needs at least 2… possibly more depending on ‘reliability’ of trigs)

anyway… thats the fun of modular for me… theres a lot of fun quirks out there waiting to be discovered.

1 Like
#340

yes, with all these cool modules, there are some very interesting structures emerging. I tried using the LFO to modulate the forward/backward playback of GRA4, but it seems like the pitch is fixed on the time of trig and doesn’t track during playback? Need to test more. Very thankful for all of these great modules now coming together. Sometimes it’s the simple modules that make as great match for the bigger more complex ones. The FFT filter works great mixed in, and the FFT makes a lot of related voltage modulation.

&e

#341

absolutely as expected.
in granular synthesis, grain properties are always set when triggering.
its one of the reasons using very short grains are so popular/effective.
(I know many use them with longer grains as a kind of sample player, but this is not its purpose,
and would ‘lack features’ for that purpose)

a good example of this in granular is… ‘grain clouds’
basically, you create lots of grains, using minor modulations, then put into a reverb to wash them together…
here if you want to play a longer sample, you do this by using short grains, and then modulating the start position with a phasor.

of course, like everything, granular vsts/modules have added features. so often are ‘hybrids’ , so might have things like playback speed… where its essentially using internal phasors.
but GRA4 is much more the building block for traditional granular synthesis.
(thats kind of what I meant in the docs, about creating it as a lower level alternative to GRA)

1 Like
#342

Understood, thanks. :+1:

#343

Same here and it should be solved or being explained how to avoid this !!

3 Likes