Back on the patches now, time for polyloadable subfolder rabbit holes
-
@willjames25 Meaning it has to have x type of inputs, x type of outputs right off the bat, has to respect the poly language and so on. Makes everything speak in the same dialects
@Nixtrove right so poly would be the only way of having your patches lined up & ready to use without them being open somewhere in the patch eating up cpu? Have you implemented that same idea within the actual patches, my thinking moved towards it for that reason really , like you might have a synth/sampler etc. with features you know you’ll only use here or there or just taking up unnecessary space & it would be nice to open it up as a separate patch
-
@willjames25 Poly is well optimized which is great, the loading is very sub-perceptual and in terms of the subroutines the poly introduces, it can get hard to mentally manage although it’s just a matter of being very familiar with the signal flow and seeing the most appropriate places poly can end up in, my approach being a bit decentralized, big cthulu patches hosting smaller patches (so there’s a linear hierarchy of patches in my case). You can also turn off DSP in poly.
@Nixtrove @willjames25 hmm how do you handle recalling what’s inside the poly’s? I’ve always done it with two separate pattrstorage. One for the “loader”, to recall the right patch and another pattrstorage inside that loaded patcher to get the actual params. Can you get away with just the one maybe?
-
@Nixtrove right so poly would be the only way of having your patches lined up & ready to use without them being open somewhere in the patch eating up cpu? Have you implemented that same idea within the actual patches, my thinking moved towards it for that reason really , like you might have a synth/sampler etc. with features you know you’ll only use here or there or just taking up unnecessary space & it would be nice to open it up as a separate patch
@Nixtrove that sounds like a big positive to building a framework for your patches to exist in. I imagine it’s a a refreshing feedback loop to be in when you’re also constantly reiterating the system to benefit patches and vice versa . The one thing that stumps me seeing these sorts of environments is how cohesive 1 hour performances are done & how controller controller mapping is switching throughout a set , it’s wizardry to me
-
@Nixtrove right so poly would be the only way of having your patches lined up & ready to use without them being open somewhere in the patch eating up cpu? Have you implemented that same idea within the actual patches, my thinking moved towards it for that reason really , like you might have a synth/sampler etc. with features you know you’ll only use here or there or just taking up unnecessary space & it would be nice to open it up as a separate patch
@willjames25 I sort of leave everything “on”, Macs can handle a lot of data, usually it’s stuff like gen~ and MC that can eat up your cpu there, pattrstorage as well, so it’s nice to only have a sound ring out when it’s needed kind of thing (talking DSP specifically). I’ve sort of abandoned rearranging the guts of my preliminary work because I just want to do new stuff, just happy my stuff runs fine as it is after a lot of debug and now it’s about pushing the limit a bit
-
@Nixtrove right so poly would be the only way of having your patches lined up & ready to use without them being open somewhere in the patch eating up cpu? Have you implemented that same idea within the actual patches, my thinking moved towards it for that reason really , like you might have a synth/sampler etc. with features you know you’ll only use here or there or just taking up unnecessary space & it would be nice to open it up as a separate patch
@willjames25 Meaning it being advantageous to turn off complex patches loaded in poly~ if your cpu levels are already redlining here and there, which only poly does as far as I know, with scheduler rate stuff you could also stop individual schedulers in poly
-
@Nixtrove @willjames25 hmm how do you handle recalling what’s inside the poly’s? I’ve always done it with two separate pattrstorage. One for the “loader”, to recall the right patch and another pattrstorage inside that loaded patcher to get the actual params. Can you get away with just the one maybe?
@chrisorstedt @willjames25 Each patch having a pattstorage system, the poly loader itself being its own abstraction and using either hardcoded or send/receive data recalls to pull up Sequencer A in subfolder A on pattr 1,2,3 for example. Just a standardized kind of communication method so everything fits the poly ecosystem, using a pattrstorage for the actual loader makes sense. In my case it’s not a burning need but it does work well I think
-
@Nixtrove I’m aware that you can create a umenu & send your patch names to poly for it to open but I’m probably missing a lot of its other useful features , especially when it comes to putting a framework in place for having changeable patches. I love what you mentioned about things only dropping in at the end of the bar, like I do that with speedlim a lot or latch in gen but I can imagine that being mental once it’s incorporated into the framework
@willjames25 @Nixtrove how is using latch in gen working for you? I was thinking about using that alot more to reduce glitches when preset switching , cause its on the audio thread rather than the scheduler
-
@willjames25 @Nixtrove how is using latch in gen working for you? I was thinking about using that alot more to reduce glitches when preset switching , cause its on the audio thread rather than the scheduler
@Glubhorn9 @Nixtrove it's perfect for reducing glitches for what I'm doing which is mainly samplers in mc.gen. the first inlet will just be a click impulse and that will be resetting an internal phasor as well as param changes from outside, it's nice dialing in changes and knowing you have a set amount of time before those changes update, I rely on It heavily though, it's super smooth and find it cool for internal sequencing within synths too
-
@Glubhorn9 @Nixtrove it's perfect for reducing glitches for what I'm doing which is mainly samplers in mc.gen. the first inlet will just be a click impulse and that will be resetting an internal phasor as well as param changes from outside, it's nice dialing in changes and knowing you have a set amount of time before those changes update, I rely on It heavily though, it's super smooth and find it cool for internal sequencing within synths too
@willjames25 @Nixtrove you mean audio rate sequencing?
-
@willjames25 @Nixtrove you mean audio rate sequencing?
@Glubhorn9 @Nixtrove i've tried audio rate sequencing where maybe the internal main pitches are doubling/halving at audio rate, for param changes though, a lot of the time I'll have internal delays changing certain params once a new pitch triggers a click within gen. there might be set params within gen that are being sequenced by chance using mix as well. have you tried audio rate sequencing ? I haven't delved into it too much. I'm a gen novice tbh when it comes to the technicalities
-
@Glubhorn9 @Nixtrove i've tried audio rate sequencing where maybe the internal main pitches are doubling/halving at audio rate, for param changes though, a lot of the time I'll have internal delays changing certain params once a new pitch triggers a click within gen. there might be set params within gen that are being sequenced by chance using mix as well. have you tried audio rate sequencing ? I haven't delved into it too much. I'm a gen novice tbh when it comes to the technicalities
@Glubhorn9 @Nixtrove pretty sure this was the result when trying to sequence at audio rate
-
@Glubhorn9 @Nixtrove pretty sure this was the result when trying to sequence at audio rate
@willjames25 @Glubhorn9 love this
