Sfplay~ Remove files from sfplay object to stop playback. Building Drum Machine
Hey guys,
First time poster here. I started working with Max during university and after a long period off I have come back to a few projects I started a while back. Feeling pretty rusty and a little unsure of myself. I am an avid user of the help and reference files but sometimes it seems that I find it difficult to articulate a particular problem in a way that makes it easy to search answers. Maybe I'm not alone in this, or perhaps it just reveals a lot about my ability to articulate!
Anyway, long story short I am currently building a drum machine based around Roland style step sequencing. I am doing this with sfplay~ objects for each part of the kit. My plan is to enable the user to load specific kits with a Umenu, as well as to change each sample independently for custom kits.
So far I have had success with this using a Umenu to produce numbers (linked to text entries - '626'. '707' etc), which bang open messages for each sample in the appropriate sample folder. However, as you will know, some of these older machines have less sounds than others, meaning that previous samples are left in the remaing Sfplay~ objects. My question is, is there a way to send a 'dummy' message or 'unload' message to the Sfplay~ objects which will not be used for each drum kit 'template'. I would prefer the user to add extra sounds if they wish, and not to be forced into some sort of hybrid 606/909, for example.
I've attached a screenshot of my basic Umenu configuration as it stands, which was fine when I was only using 3-4 samples per part of the kit. I would like to keep this section for individual sample choices but provide a master section to override it for choosing a full kit. Think of it like Redrum in Reason, with the ability to change individual samples and full kits. This is only one of 10 sequencers, one for each part of the kit.
If this is a bit long winded and rambling, I apologise, and refer you back to the first paragraph. I'm not trying to reinvent the wheel here, with such an unoriginal patch, just trying to increase my Max knowledge with a project which is both interesting and rewarding in terms of my interests and usability. I can post the full patch if anyone would like to see it, though it is getting pretty large and unwieldy!
Any advice would be greatly appreciated. I'm not looking for a thorough walk through but a point in the right direction (tutorials, help files etc).
Cheers for your time!
Or alternatively, a better way of doing it altogether?
You can send fclose message to sfplay to unload opened file.
Also clear message to unload cues.
Thanks for the reply Source Audio. the fclose message works perfectly, cheers. I tried the clear message originally but it deletes all the data from the Umenus and I have to enter it all again.
If anyone else has any better way of managing the samples in the way I described please let me know. I've been trying to wrap my head around the coll object as I think it might help me.
Clear message would remove items in umenu only if Yoy send a clear message to umenu,
definitely not if You send it to sfplay...
Now about sample management - it is all about organising samples on harddrive, and loading them
into sfplay objects.
So if You want to load 10 Drum Sets and allways use same sfplay for kicks, next one for snares etc
one could also make such a structure on HD, folder for kicks, folder for snares etc.
Prepend Drum Set number into sound name, like 01-Snare.aif 02-Snare.aif etc
then each sfplay could have own umenu filled with samples of same kind , and when You load Drum Set 1
all sfplays load sample number 1. That could be one possible scenario.
The other one colud be having all samples belonging to one Drum Set in one Drum Set folder,
so that all sfplays share same folder path, but each loads just it's sample.
Then one would use sprintf to group Folder Path and add Sample name to it.
like [sprintf symout %s/Kick.aif] would result in for example "Mac-Hd://DrumKits/Tr-909/Kick.aif"
To be sure no sfplay keeps old sample inside if Drum set does not have that instrument,
one could send message fclose, open "Mac-Hd://DrumKits/Tr-909/Kick.aif"
But I would suggest not doing so, but using some other logic to prevent receiving
notes in sfplay object which has no Instrument in Drum Set.
Well I could go on for hours like that throwing ideas, it all depends also on how many Drum Sets would be in use,
if Samples need polyphony ( like Crash Cymbal that should have 2 Samples sounding when hit before first sample fades out
and many other factors.
Not to forget preload option for sfplays.
Thanks, again, for all the advice. I'm going to try a lot of what you suggested tonight. Interesting point about the polyphony aspect - I had thought about that at an earlier stage and it seems to have been forgotten in the experimenting with sample loading.
I have had a lot of luck with message boxes clearing and delivering the sample files into Umenu, followed by a bang (observing Max processing hierarchy) to load the sample into Sfplay~. The problem comes when trying to use a custom kit. By clearing all samples before loading in a specific kit, I am removing the ability to use samples not connected to each kit model. I think the best course of action for me would be to continue with this model and then work towards an alternative later. Perhaps utilising this model for a sample bank. Thinking out loud here!
Thanks again for all your help. Definitely food for thought!
Now thinkig loud as well, You could be quite flexible.That is all about umenus, and storage.
You can ofer preprogrammed Kits like Tr-808 etc, but also allow combining of
individual samples into custom Drum Kits.
If You have first item in umenu --- and then add samples, one could take ---
as "no sample" for that sfplay, and use it to close gate for incoming notes.
For polyphony, maybe buffer~ / groove~ combination would be more efficient.
One would load Sample into 1 buffer, and use several groove~ objects for playback.
Start message (for playback start) could trigger a bang wich wold change gate outlet
so that next start message goes to next groove~ object.