Back on the patches now, time for polyloadable subfolder rabbit holes
-
What’s great about that is that I get to patch more, poly the gift that keeps on giving. Loading up some weird patch in the middle of some other thing sounds kinda fun
What’s also perhaps a funny little con to poly is that I’m gonna have thousands of unfinished patches in a few years, but what doth “finishing a patch” even mean…
-
What’s also perhaps a funny little con to poly is that I’m gonna have thousands of unfinished patches in a few years, but what doth “finishing a patch” even mean…
This post is deleted! -
What’s also perhaps a funny little con to poly is that I’m gonna have thousands of unfinished patches in a few years, but what doth “finishing a patch” even mean…
@Nixtrove how do the poly patches slot into your chain ? Is there a routing system set up that just allows you to mix in fx etc. I am veering towards setting up a little submenu folder for this in a sampler I’m working on but also intrigued how you have implemented this with sequencing data ?
-
What’s great about that is that I get to patch more, poly the gift that keeps on giving. Loading up some weird patch in the middle of some other thing sounds kinda fun
@Nixtrove I love poly, I love poly of polys too.
-
What’s great about that is that I get to patch more, poly the gift that keeps on giving. Loading up some weird patch in the middle of some other thing sounds kinda fun
-
@Nixtrove how do the poly patches slot into your chain ? Is there a routing system set up that just allows you to mix in fx etc. I am veering towards setting up a little submenu folder for this in a sampler I’m working on but also intrigued how you have implemented this with sequencing data ?
@willjames25 Working off the specific architecture I conceived a few years ago and implemented, it’s really just a matter of mixing between what I had before and whatever can be hard-switched or slowly faded into the poly slot. It’s really just sprinkling that poly shit everywhere, where the stuff is already happening, so that particular gizmo I already have (where I put it pretty much) can just do more things. Because I do not want to overwrite my old messy system p much
-
@willjames25 Working off the specific architecture I conceived a few years ago and implemented, it’s really just a matter of mixing between what I had before and whatever can be hard-switched or slowly faded into the poly slot. It’s really just sprinkling that poly shit everywhere, where the stuff is already happening, so that particular gizmo I already have (where I put it pretty much) can just do more things. Because I do not want to overwrite my old messy system p much
@willjames25 Still a WIP but I’m thinking it being pretty easy, just to queue switches between the main sequencers I have and then the poly sequencers. Downbeats pretty much, slow fades, but yeah just imagine putting a poly right next to anything you have and then switch to the poly patch slot (whatever’s in there) whenever you want, that’s the kind of freedom I’m thinking of.
-
Back on the maxpatching now, time for polyloadable subfolder rabbit holes
@Nixtrove i'm there atm
Any tips on loading patches in real time without audio interrupting? -
@willjames25 Still a WIP but I’m thinking it being pretty easy, just to queue switches between the main sequencers I have and then the poly sequencers. Downbeats pretty much, slow fades, but yeah just imagine putting a poly right next to anything you have and then switch to the poly patch slot (whatever’s in there) whenever you want, that’s the kind of freedom I’m thinking of.
@willjames25 Like the difference between something you hard coded and something that’s swappable. I’m not getting rid of the hard-coded stuff (say it like the machine as it already is) I’m just adding the swappable stuff. I will be pretty much recycling audio channels and message/event cables and inserting poly~ hosted data and sounds into the same routing. I could run down the core architecture in a separate post or in PM
-
@Nixtrove I love poly, I love poly of polys too.
@jules_rawlinson You.. can do that?
-
@skogn Wake up and smell the poly
-
@Nixtrove i'm there atm
Any tips on loading patches in real time without audio interrupting?@noxin I’m thinking you could use a very quick crossfade between the channels, or a mute/solo thing, pretty much sleight of hand with a mixer except it’s in Max
. Stealing DJ techniques. -
@noxin I’m thinking you could use a very quick crossfade between the channels, or a mute/solo thing, pretty much sleight of hand with a mixer except it’s in Max
. Stealing DJ techniques.@Nixtrove that's what i was thinking, gotta try it. Thanks!
-
@willjames25 Like the difference between something you hard coded and something that’s swappable. I’m not getting rid of the hard-coded stuff (say it like the machine as it already is) I’m just adding the swappable stuff. I will be pretty much recycling audio channels and message/event cables and inserting poly~ hosted data and sounds into the same routing. I could run down the core architecture in a separate post or in PM
@Nixtrove I get you , it does sound refreshing having a framework laid out so you can easily access you’re patches & layer - have them meld together as a result of data being shared between them and so on. I normally work on patches in max as these contained projects / tools that become a sort of performance environment. Not knowing a lot about poly, is there particular features baked in that lend itself to it being more appropriate for building swappable chains of patches?
-
@Nixtrove I get you , it does sound refreshing having a framework laid out so you can easily access you’re patches & layer - have them meld together as a result of data being shared between them and so on. I normally work on patches in max as these contained projects / tools that become a sort of performance environment. Not knowing a lot about poly, is there particular features baked in that lend itself to it being more appropriate for building swappable chains of patches?
@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
-
@Nixtrove I get you , it does sound refreshing having a framework laid out so you can easily access you’re patches & layer - have them meld together as a result of data being shared between them and so on. I normally work on patches in max as these contained projects / tools that become a sort of performance environment. Not knowing a lot about poly, is there particular features baked in that lend itself to it being more appropriate for building swappable chains of patches?
@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 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 It begets managing your patches in a more structured manner, being able to keep your stuff visible and findable, loadable, so it also does morph your workflow into something a little more coherent for the average person I would say, probably making it nice for collab. I think in terms of how it affects future patching habits I think it is also positive, you are already determining the end result of the signal chain so the patch itself becomes efficiently coded
-
@willjames25 It begets managing your patches in a more structured manner, being able to keep your stuff visible and findable, loadable, so it also does morph your workflow into something a little more coherent for the average person I would say, probably making it nice for collab. I think in terms of how it affects future patching habits I think it is also positive, you are already determining the end result of the signal chain so the patch itself becomes efficiently coded
@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
-
@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?
