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…

@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 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 between outputs maybe a bit of bleed of both, 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 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

@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

@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