Flowchart | Seeking advice and suggestions on multiple scenarios and states/behaviours mapping
Hi everyone, another rookie here asking for suggestions and advice on how to approach and resolve a couple of challenges I'm facing in a Max MSP project I'm currently working on (like crazy honestly).
I literally just picked up Max MSP 2 weeks ago for the first time in my life so apologies if I sound absurd.
The idea is to create a system with 7+ speakers that perform with me on stage (volume/duration/pitch of my voice trigger particular playlists with random samples) and are able to 'communicate' with each other, but only in some cases (important). What I mean by that is to have a scenario in which once one speaker is playing, it actually triggers the ones that are left and right to it. But then in another scenario, I want all 7 of them to start at the same time.
I have two sets of incoming data: my live voice input (pitch, duration, volume) and a drunk sensor I set up to simulate an ultra-sonic sensor I'll actually be using when performing down the track.
On the output side, I have 7 speakers with 2+ datasets (playlists) of 20+ pre-recorded samples that each of the speakers should play randomly when appropriate (also important, meaning that it has to fulfill certain conditions).
What I am most troubled by at this stage is how to structure the patch - the way I outlined it so far is like this (the patch is attached below, unfinished):
input data (voice [3 x f] + drunk simulator/sensor [7 x int])
pak
route list
conditions (if xy do this, if xz do that etc)
route fulfilled statements to the right playlist
trigger and play the adjacent behavior (play once, trigger next speaker, loop one sample)
The biggest challenge right now is the bottom part of the patch - once I know what the speakers should play, how can I change between multiple playlists AND behaviors (for example: speaker 1 play random sample on playlist 1 just once but trigger speaker 2?)...unsure my question makes sense? The thing is that I want the drunk sensor to be the one determining which speaker is the 1st one to start playing (instead of just going 1 2 3 4 5 etc). I've managed to get to that point, but now switching between all these multiple scenarios seems super complex...
I am aware that this is a big project to tackle as a newbie, but I like challenges :) I feel like this is quite important to tackle since I do wish this system to be scalable without breaking so want to think in advance about how to create an optimal data flow.
Any advice, direction, suggestion, or criticism is very appreciated.
Thanks in advance and sorry if I explained it poorly, my brain feels like scrambled eggs atm :)
Can't realy have a close look at your patch , my macbook has small screen, so it would take some time to reposition everything to fit.
Just few thoughts. Apart from parts of the patch than can/should be reduced and optimised,
it is important to set input and output rules, which would not be so difficult, but
when it comes to logic, like if player xy is now playing and rules are so and so,
then next 2 players should ...
You need clear hierarchy of events that trigger and affect each other,
and that can be developed and simulated without really running all sensors.
Most important is to avoid repeated sensor inputs, and to keep "brain" in central place,
don't let each player talk to all others (including itself) but collect current inputs and states, and route output to destinations once all rules are set and states satisfied.
I know it sounds a bit theoretical, if you get stuck in one or the other part of your project, it is sometimes easier to get help with individual parts then with the whole aparatus, which needs time to get looked at, analysed etc.
Personally, I would stay away from that many playlists, unless you load each playlist with different samples.
I would rather use umenu populated with sounds and use sfplay~ for playback.
All players can share, grab samples from same folder (or populated umenu).
P.S. pozdrav is Dubrovnika
Hey @sourceaudio
Hvala za tako brzi odgovor! :)
You're definitely right, especially when it comes to top/bottom-level rules, they should be clearly determined. Also, I think you actually got me a really good idea with sfplay; I do have multiple playlists for a reason (have a set of audio samples for each behaviour) but instead of having multiple playlists, I could just consolidate them into one folder and control which set is playing....
Thanks for this, I know my question is too broad and not necessarily very specific, I just wanted to pick other people's brain to see if I am looking at this patch the wrong way and should re-arrange its top level structure.
na usluzi , you are welcome.
You actually make amazing progress after only few weeks with Max,
the most difficulty is that one can do one and the same thing in many ways,
one usually picks first known option, it needs quite some time spent with that many max objects, to really pick the best solutions.
Like that pitch detector for example..