v_54

Hi, I am quite new to max and have searched and found some topics on sequencers but they are all too complex ideas for what I need personally.

Basically I would like to create a simple sequencer similar to the 'music creation' program called dance/hip-hop ejay. But I have recorded real instruments such as drums, bass, guitar etc.

The user will have a set track for each instrument - probably around 5 or 6 tracks. 

Each track will be divided into bars, where the user will be able to select from a list of samples for that particular bar. then once the choice of samples is complete, all tacks hould play back as a full song.

All samples are same tempo / key, and each sample will be cut to the exact same length. All that is needed is for the sampels to play back in time.

I had thought of using coll to store the samples for each instruments, then using a pop-up list to represent each bar.

If this is possible then other features such as volume/ solo/ mute options will be added.

The user will have a set track for each instrument - probably around 5 or 6 tracks. 
Each track will be divided into bars, where the user will be able to select from a list of samples for that particular bar. then once the choice of samples is complete, all tacks hould play back as a full song.

very-basic-audio-sequencer

Sounds like a great project for Max. I particularly like the simplicity of it---often our ideas get very very complex in Max, which can be great fun, but also confusing. The fact that your samples are the same length, tempo, and pitch make things easy.

A drop-down for your sample names is great. If there are spaces in the filename I believe you need to use quotes around the name when you send the buffer~ or sfplay~ your "read" message. (drop-down --> prepend read --> buffer~ name_of_track). You'd have a separate buffer~ and groove~ object for each track. You can change the loop points and speed and such too, but for this it doesn't sound like you will want to.

Coll won't store the samples---buffers do that. Coll is used for indexed lists---one use would be to store the *names* of the sample files (unless that's what you meant). If so, then the drop-down could simply access the sample names by index number. Maybe the topmost entry in the drop-down would be blank, so no sample plays in a particular bar?

If you use sfplay~ for your samples instead of buffer~ and groove~ (which you certainly could) then the bang out the right outlet signals that it's done playing and should look for / play the next sample / file. Since everything is the same tempo and length, you don’t need any kind of universal or track-specific timing---the indicators at the ends of the files will trigger the next ones.

For volume, solo, mute – very easy and you should have them, certainly. Each groove~ or sfplay~ object (one per track) is connected to R and L gainfaders... there’s your volume and pan right there. Solo will just zero out the rest and mute will zero out the current one(s). Some logic required but not bad, and good to learn. It’s tempting but DON’T use a gate~ to mute / solo---you’ll get clicks. Instead you should store the pairs of slider values (right outlet) for each track with a set $1 to a number box; zero out the two faders of the track when muting; then bang the stored values back in (left inlet) on unmute. Use Get Info on the faders to set the interpolation (fade) time for each---default 10 ms, you might try 50 or so. This will be a clean, no-click, quick fade (you can set longer ones if you like). All the tracks L and R go into a set of master faders that controls the overall mix. Then there’s effects options... well, that’s down the road perhaps. ;)

Try the breakpoint function editor---you can set an overall envelope for volume, either by track and / or global. Great stuff. Also use a preset object that’s attached to all your drop-downs. This way you can store whole sets of sample choices for each track and bar, and easily change whole layouts with one click (and those can be automated too). Presets for the volume levels would also be nice.

Check out the mtr object too... automation of just about anything you want, it’s fantastic. Plus you should have a sfrecord~ after the master faders---you want to save your mixes, right? Sure... why not.

There’s really no end so I’ll stop there. Good to keep things simple for now, but I’m sure you’ll want to explore more. Did I mention there’s no end? ...end? ..........end?

For volume, solo, mute – very easy and you should have them, certainly. Each groove~ or sfplay~ object (one per track) is connected to R and L gainfaders... there’s your volume and pan right there. Solo will just zero out the rest and mute will zero out the current one(s). Some logic required but not bad, and good to learn. It’s tempting but DON’T use a gate~ to mute / solo---you’ll get clicks. Instead you should store the pairs of slider values (right outlet) for each track with a set $1 to a number box; zero out the two faders of the track when muting; then bang the stored values back in (left inlet) on unmute. Use Get Info on the faders to set the interpolation (fade) time for each---default 10 ms, you might try 50 or so. This will be a clean, no-click, quick fade (you can set longer ones if you like). All the tracks L and R go into a set of master faders that controls the overall mix. Then there’s effects options... well, that’s down the road perhaps.  ;)

Try the breakpoint function editor---you can set an overall envelope for volume, either by track and / or global. Great stuff. Also use a preset object that’s attached to all your drop-downs. This way you can store whole sets of sample choices for each track and bar, and easily change whole layouts with one click (and those can be automated too). Presets for the volume levels would also be nice. 

Glad you like the idea...I am trying the first thing you suggested:

"A drop-down for your sample names is great. If there are spaces in the filename I believe you need to use quotes around the name when you send the buffer~ or sfplay~ your "read" message. (drop-down --> prepend read --> buffer~ name_of_track). You'd have a separate buffer~ and groove~ object for each track. You can change the loop points and speed and such too, but for this it doesn't sound like you will want to."

I am going to work on one track first then the others will obviously be the same... I have a line of drop down 'umenu' objects. So am I to follow this by a 'prepend read' object then is it 'buffer~ "Name of Track' or 'buffer~ 'Name of Sample'? Will each drop down list, or "bar" of the track have its own read - buffer etc. or should the track share one?

That's a good point -- you probably should have a separate buffer~ for each bar so there's no lag when loading in new samples. They would all load in before you start playing, and since most of the time things would be looping (i.e., not changing samples as much as letting it play) that would make things smoother.

I don't know whether it might be better to have all your "related" samples (i.e., like the 8 different bass lines that you use or whatever) put together into one longer sample that is accessed at different points in each bar (depending on which section is chosen to play). There may be an advantage to this "smooth-wise" too. You could easily paste the samples together in a different audio program and make these files, then have a single buffer~ and groove~ object per track (instead of per bar) that reads the appropriate section. It would give you experience working with loop points too which is good, and the editing would give you a chance to put in short crossfades on the sample sections (to avoid clicks when changing samples or looping, see elsewhere on the forum for a number of discussions on this).

Check out the help on buffer~, it's all there. I usually use replace because it always reads in the whole file, which is better mentally for me (unless the file is huge...) Thinking about all this I would go for groove~ and buffer~ rather than sfplay~, I think you'll have better playback.... though admittedly my experience comparing the two is limited.

Like to see (and hear) what you come up with!

I will email you when I have it finished!

I am trying to use coll to select the sample to read into buffer~

so say you select option 2 on the pop up list - which sends a 1 to coll, the first output from coll is then sent to prepend read (or replace?) object but the message coming out of this shows ' replace symbol "Drum1.wav" '

I am guessing the symbol part of this is due to the coll values being words rather than numbers. Is there a better way of doing this? or perhaps a way of removing the symbol element?

these samples are contained in the same folder as the patch.

I will email you when I have it finished! 

these samples are contained in the same folder as the patch.


will get back to you later tonight, must go for now. stay tuned ;)

you can manage elements of lists (add and remove, replace, etc.) using zl slice (remove / separate elements), prepend, substitute (though probably not needed here) and sprintf. This may be needed to manage your read/replace messages. also "route symbol" etc.

will get back to you later tonight, must go for now. stay tuned  ;)

Hey, I am getting further on with this project now , gradually.. I am able to use the drop down lists to replace samples in buffer objects which groove then can play. I now need a way of triggering the next sample in the sequence to play.

I have tried a snapshot object from the right outlet of groove~ which sends a bang at the end of the sample (an object of >= 0.99 makes this happen), but as the sample only plays once, the value stops at 0.99 and therefore the bang just keeps triggering , meaning the next sample in the sequence cannot play. I am having to use a different buffer and groove for each sample.. if there is a way I can just use one for all samples it would be great.

I can also use a metro set to the sample length which sends a bang everytime but I am unsure how to use this to trigger the sequence one by one.

Any help or ideas again greatly apprciated

Hey, I am getting further on with this project now , gradually.. I am able to use the drop down lists to replace samples in buffer objects which groove then can play. I now need a way of triggering the next sample in the sequence to play. 

Any help or ideas again greatly apprciated 

I have tried a snapshot object from the right outlet of groove~ which sends a bang at the end of the sample (an object of >= 0.99 makes this happen), but as the sample only plays once, the value stops at 0.99 and therefore the bang just keeps triggering , meaning the next sample in the sequence cannot play. 

In a sequencer, you want them each to play just once, right? Sometimes you need a "startloop" to get them each going... The >= 0.99 is an idea, but you may have problems, because there is no guarantee that the signal output from groove actually will get over 0.99--- if the sample is short it may only get to (say) 0.97. I also am wondering how to manage this for short samples with groove~, so I would like to hear from someone who knows more about this... how to tell when the loop has finished, with sample-accurate precision? What if the loop is going backwards?

You might consider looking at count~, because if you know the total sample length, count~ can be used to output exactly as many samples as you'd like, then use a ==~ operator to see when it's done.

I am having to use a different buffer and groove for each sample.. if there is a way I can just use one for all samples it would be great.

You should use a different one so that you son't have to load the new ones as you go, this would make screwy timing probably.

The idea is right, but the metro is *NOT* completely accurate in timing (well-documented and not designed to be). Look up the help on sync~ and use a phasor~ to set any kind of clock you need to be accurate. The DSP deals with timings much more precisely and reliably than metro.

For one-by-one, the bangs that come out of you DSP / phasor~ etc. clock should go into a counter, then use comparisons (== 1, == 4, etc.) or a "select 1 5 9 13" (for example) to trigger a bang every four counts.

Hope this helps.... keep me posted! Would like to see a patch sometime if you're willing.

----------
I have tried a snapshot object from the right outlet of groove~ which sends a bang at the end of the sample (an object of >= 0.99 makes this happen), but as the sample only plays once, the value stops at 0.99 and therefore the bang just keeps triggering , meaning the next sample in the sequence cannot play. 
--------------

In a sequencer, you want them each to play just once, right? Sometimes you need a "startloop" to get them each going... The >= 0.99 is an idea, but you may have problems, because there is no guarantee that the signal output from groove actually will get over 0.99--- if the sample is short it may only get to (say) 0.97.  I also am wondering how to manage this for short samples with groove~, so I would like to hear from someone who knows more about this... how to tell when the loop has finished, with sample-accurate precision? What if the loop is going backwards?

-------------------
I am having to use a different buffer and groove for each sample.. if there is a way I can just use one for all samples it would be great.
-------------------------

----------------------
I can also use a metro set to the sample length which sends a bang everytime but I am unsure how to use this to trigger the sequence one by one.
----------------------
The idea is right, but the metro is *NOT* completely accurate in timing (well-documented and not designed to be). Look up the help on sync~ and use a phasor~ to set any kind of clock you need to be accurate. The DSP deals with timings much more precisely and reliably than metro.

Hope this helps.... keep me posted!  Would like to see a patch sometime if you're willing.

I am now using an sfplay~ which uses one large audio file containing all samples and cues can be used to select each section of the file to play. The sfplay sends a bang when each cue is finished. Any ideas on how I could select an order in which the cues should be played?

Quote: v_54 wrote on Thu, 22 March 2007 17:19

----------------------------------------------------

> I am now using an sfplay~ which uses one large audio file containing all samples and cues can be used to select each section of the file to play. The sfplay sends a bang when each cue is finished. Any ideas on how I could select an order in which the cues should be played?

Hi, just wondering, what keeps you from using Ableton Live?

Quote: v_54 wrote on Thu, 22 March 2007 17:19
----------------------------------------------------
> I am now using an sfplay~ which uses one large audio file containing all samples and cues can be used to select each section of the file to play. The sfplay sends a bang when each cue is finished. Any ideas on how I could select an order in which the cues should be played?
----------------------------------------------------

Load all your cues in preloads (using sfplay~), then you can send a 

list of ints to sfplay~ specifying the order you want to play each 

cue, e.g. a single message of "4 6 5 7 2" will play cue 4, then 6, 

On Mar 22, 2007, at 9:19 AM, Will Cory wrote:

> I am now using an sfplay~ which uses one large audio file 

> containing all samples and cues can be used to select each section 

> of the file to play. The sfplay sends a bang when each cue is 

> finished. Any ideas on how I could select an order in which the 

Load all your cues in preloads (using sfplay~), then you can send a  
list of ints to sfplay~  specifying the order you want to play each  
cue, e.g. a single message of "4 6 5 7 2" will play cue 4, then 6,  
then 5, then 7, then 2.

>
> I am now using an sfplay~ which uses one large audio file  
> containing all samples and cues can be used to select each section  
> of the file to play. The sfplay sends a bang when each cue is  
> finished. Any ideas on how I could select an order in which the  
> cues should be played?


Quote: David Beaudry wrote on Thu, 22 March 2007 14:42

> Load all your cues in preloads (using sfplay~), then you can send a 

> list of ints to sfplay~ specifying the order you want to play each 

> cue, e.g. a single message of "4 6 5 7 2" will play cue 4, then 6, 

> On Mar 22, 2007, at 9:19 AM, Will Cory wrote:

> > I am now using an sfplay~ which uses one large audio file 

> > containing all samples and cues can be used to select each section 

> > of the file to play. The sfplay sends a bang when each cue is 

> > finished. Any ideas on how I could select an order in which the 

So i could use drop down lists to create an order of cues..? I want the user to be able to chose the samples to play.. so there would be a preset amount of pop-up lists, which will in turn create a list.. I am using preloads to save cues now. I just need a way the order of these can be chosen in a simple interface (hence the choice of pop up lists) its late so I havnt read all the replies properly yet, I will reply further tomorrow but thanks all for replying!

Quote: David Beaudry wrote on Thu, 22 March 2007 14:42
----------------------------------------------------
> Load all your cues in preloads (using sfplay~), then you can send a  
> list of ints to sfplay~  specifying the order you want to play each  
> cue, e.g. a single message of "4 6 5 7 2" will play cue 4, then 6,  
> then 5, then 7, then 2.
>
> David
>
>
> On Mar 22, 2007, at 9:19 AM, Will Cory wrote:
>
> >
> > I am now using an sfplay~ which uses one large audio file  
> > containing all samples and cues can be used to select each section  
> > of the file to play. The sfplay sends a bang when each cue is  
> > finished. Any ideas on how I could select an order in which the  
> > cues should be played?
>
>
----------------------------------------------------

So i could use drop down lists to create an order of cues..? I want the user to be able to chose the samples to play.. so there would be a preset amount of pop-up lists, which will in turn create a list.. I am using preloads to save cues now. I just need a way the order of these can be chosen in a simple interface (hence the choice of pop up lists) its late so I havnt read all the replies properly yet, I will reply further tomorrow but thanks all for replying!


"e.g. a single message of "4 6 5 7 2" will play cue 4, then 6, 

This seems to be gettin me very close to what I need.

Is there a way a list of ints can be created by a user with the pop up lists?

This would then be sent to the sfplay object when a 'play' button is pressed which will trigger the cues.

"e.g. a single message of "4 6 5 7 2" will play cue 4, then 6, 
then 5, then 7, then 2."

Is there a way a list of ints can be created by a user with the pop up lists? 

This would then be sent to the sfplay object when a 'play' button is pressed which will trigger the cues.


Rather than pop-up menus, why not just use [textedit] to have the 

user type in the sequence of cues? The typed list is sent when the 

user hits the 'return' key. See the following:

On Mar 25, 2007, at 11:19 AM, Will Cory wrote:

> Is there a way a list of ints can be created by a user with the pop 

> This would then be sent to the sfplay object when a 'play' button 

> is pressed which will trigger the cues.

Rather than pop-up menus, why not just use [textedit] to have the  
user type in the sequence of cues? The typed list is sent when the  
user hits the 'return' key. See the following:

> Is there a way a list of ints can be created by a user with the pop  
> up lists?
>
> This would then be sent to the sfplay object when a 'play' button  
> is pressed which will trigger the cues.

Yes may be easier to do that but the idea is to have a user friendly interface so they can just chose rarther than type. Butthat is a good back up plan. As I am having 5 different 'tracks' i would need the list for each track to be sent at the same time so for example the tracks for drums, bass, guitar etc would all start in time. I think my first post explains the concept best. Cheers for the reply though!

Keep in mind that using some number of pop-up menus to provide the 

numbers to be selected will restrict the total number of cues in a 

given list to the number of menus available for it, unless you do 

some sort of seriously convoluted programming. Also, providing for 

the ability to change or edit the generated list before it is sent 

out could be more complicated, as well, depending on how you set it 

all up. "User friendly" interfaces also allow for the simple 

correction of 'mistakes' in user input or prevent them from happening 

BTW, with the addition of a [coll] object and some additional 

programming to my previous example you could easily synchronize the 

sending of 5 lists to 5 different [sfplay~] objects. Synchronizing 

the actual [sfplay~] objects themselves - along with the control 

On Mar 25, 2007, at 12:20 PM, Will Cory wrote:

> Yes may be easier to do that but the idea is to have a user 

> friendly interface so they can just chose rarther than type. 

> Butthat is a good back up plan. As I am having 5 different 'tracks' 

> i would need the list for each track to be sent at the same time so 

> for example the tracks for drums, bass, guitar etc would all start 

> in time. I think my first post explains the concept best. Cheers 

Keep in mind that using some number of pop-up menus to provide the  
numbers to be selected will restrict the total number of cues in a  
given list to the number of menus available for it, unless you do  
some sort of seriously convoluted programming. Also, providing for  
the ability to change or edit the generated list before it is sent  
out could be more complicated, as well, depending on how you set it  
all up. "User friendly" interfaces also allow for the simple  
correction of 'mistakes' in user input or prevent them from happening  
to begin with.

BTW, with the addition of a [coll] object and some additional  
programming to my previous example you could easily synchronize the  
sending of 5 lists to 5 different [sfplay~] objects. Synchronizing  
the actual [sfplay~] objects themselves - along with the control  
scheme - will be vital, in any case.

>
> Yes may be easier to do that but the idea is to have a user  
> friendly interface so they can just chose rarther than type.  
> Butthat is a good back up plan. As I am having 5 different 'tracks'  
> i would need the list for each track to be sent at the same time so  
> for example the tracks for drums, bass, guitar etc would all start  
> in time. I think my first post explains the concept best. Cheers  
> for the reply though!

Hi, I now have the pop up menus to select an order of cues which works once the audio file is loaded into sfplay and the preload cue messages are sent to define the cue points. I am trying to make the audio file open on load but loadbang does not seem to work, so I have tried loadmess to send an "open Drum.wav" message as well as sending the preload cues to the sfplay. I have attached the screen shot of the code - The pre loads all load in numerical order first, then the open Drums.wav is sent last, so errors occur on the cues as the audio is not yet loaded.

[img]index.php?t=getfile&id=548&private=0[/img]

What would be best for having the audio loaded and cues defined as the patch is loaded? I have tried ordering them from right to left etc but no luck?

Hi, I now have the pop up menus to select an order of cues which works once the audio file is loaded into sfplay and the preload cue messages are sent to define the cue points. I am trying to make the audio file open on load but loadbang does not seem to work, so I have tried loadmess to send an "open Drum.wav" message as well as sending the preload cues to the sfplay. I have attached the screen shot of the code - The pre loads all load in numerical order first, then the open Drums.wav is sent last, so errors occur on the cues as the audio is not yet loaded. 

What would be best for having the audio loaded and cues defined as the patch is loaded? I have tried ordering them from right to left etc but no luck?


Use a loadbang that goes to a trigger (see trigger help file, it is *very important* in some situations). This avoids the on-screen right-to-left arranging problems.

Put your cue messages (preloads) into message boxes, or all into one separated by commas. Then the loadbang-to-trigger will load the audio file first, then all the cues. Should be fine.

Hey again,
Use a loadbang that goes to a trigger (see trigger help file, it is *very important* in some situations). This avoids the on-screen right-to-left arranging problems.

Very Basic Audio Sequencer