Back on the maxpatching 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…
@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?
@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?
@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