Jimmeh

hello all, im currently in the process of building up a drum machine for a uni project. little suck at the moment, im trying to make it 16 beat sequence based with random outcomes if that makes sense.

i was just wondering if anyone could lend me a hand or can point me in a direction of a drum machine made in max i can have a look at.

hello all, im currently in the process of building up a drum machine for a uni project. little suck at the moment, im trying to make it 16 beat sequence based with random outcomes if that makes sense. 

i was just wondering if anyone could lend me a hand or can point me in a direction of a drum machine made in max i can have a look at. 

drum-machine

Probably are tons and tons out there of all flavors. I'd say roll your own. Look into matrixctrl for the sequencer control grid, maybe use a bpfunction for envelopes (volume, FX, etc), or you can use tables and / or multisliders.

This is just the start, though --- when you hook up pattr to (say) your matrixctrl you'll see you have a ton more options for generating and storing your sequences. Then it's all about adding shortcuts like fill each 4th beat, paint cells using specific value level, randomize, playback any or all rows in either direction, playback only ranges of rows, playback each or all rows at specific tempi, etc... all readily possible with metro, counter, random, modulus (%), etc.

For example, send a # from 1-16 --> %4 --> sel 0 --> this would only bang on 4, 8, 12, 16 (when remainder = 0). Then this fills in (or flips on / off) a repeating series of sequencer cells (every 4th cell).

Pattr hooked up to bpfunction will behave erratically when there are more points in one preset than another (interpolation is not exact, as makes sense when considering the data). Integer presets work fine in these cases (jumps to new data set size). The other objects all will work OK with interpolation provided the data sets are the same size.

This is just the start, though --- when you hook up pattr to (say) your matrixctrl you'll see you have a ton more options for generating and storing your sequences. Then it's all about adding shortcuts like fill each 4th beat, paint cells using specific value level, randomize, playback any or all rows in either direction, playback only ranges of rows, playback each or all rows at specific tempi, etc... all readily possible with metro, counter, random, modulus (%), etc. 

from what you're saying I'm working on the exact same thing. I just have a set of multisliders with values from 0-127 (or 0-99 if you want to work by probability)and a metro that bangs out random #s. It cycles through eash slider value and if the random # is less than that value then it plays. It's like having a likelihood that a drum will play on a given beat. Basically this creates an average or approximate beat and the drum machine fills in the gaps. 

from what you're saying I'm working on the exact same thing.  I just have a set of multisliders with values from 0-127 (or 0-99 if you want to work by probability)and a metro that bangs out random #s.  It cycles through eash slider value and if the random # is less than that value then it plays.  It's like having a likelihood that a drum will play on a given beat.  Basically this creates an average or approximate beat and the drum machine fills in the gaps.  
Is that about what you're doing?


Sounds cool. I'm away from my Max machine so I can't see the patches. I'm getting a feeling for what you're doing and it seems like a good direction. Now the question is: What else can I add? There's a lot...

The multislider is great, can work well for the probability-based usage as well as setting volume levels for each beat, or effects levels, etc. Look into pattr for that and many other objects. It's a *lot* more powerful than preset and only takes a bit longer to set up... you'll be glad you did. And if you access the stored slots by integer, it behaves just like preset.

Other ideas include the range bar to restrict the range of playback (low / high values set the counter for accessing the indices, and can then do either or both directions), variable-rate playback via metro, different rates for each track, etc.

It's good to have a multiplier for the metro if you have multiple tracks -- so one plays 2X as fast, or 1/3 as fast, based upon a master tempo (master metro setting that goes through multipliers to set individual track metro speeds). Look into the tempo object to work with bpm instead of milliseconds. And finally, remember that metro is *not* totally stable in its timing -- it's not designed for this. You need to use an audiorate clock for that (look up on the forum, or the phasor~ helpfile). This will keep tempo accurate over long periods, as it uses the audio thread rather than the scheduler thread.

Try running a sequence, then drag your window around. You'll probably notice some slowing. It may feel like a feature, but "ritardando" is much better controlled via metro than by this technique! To avoid this turn Overdrive on which puts redraw at low priority and timing at high.

Other ideas include the range bar to restrict the range of playback (low / high values set the counter for accessing the indices, and can then do either or both directions), variable-rate playback via metro, different rates for each track, etc. 

yeah thats pretty similar, im having issues with it cycling though the slider value tho. how do you make it go though each one?

Quote: Jimmeh wrote on Fri, 30 November 2007 04:13

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

Accessing multislider with a gate sounds like a lot of work. Do you know about the fetch message? It's a good idea to consult the reference manual regularly. Nobody can remember all those messages...

I also like using multisliders for a progress bar (current beat indicator). Here's a small example.

Quote: Jimmeh wrote on Fri, 30 November 2007 04:13
----------------------------------------------------
> oh wait got it with a gate.
----------------------------------------------------

Accessing multislider with a gate sounds like a lot of work. Do you know about the fetch message? It's a good idea to consult the reference manual regularly. Nobody can remember all those messages... 

How about accurate (the triggering engine is based on signals), polyrhytms:

more cpu friendly is to store multislider data in value objects/one for each step/... then use sprintf to call the appropriate step and send data to the sound generator

....Moreover multislider doesnt display low values properly. For clear interface I strongly reccomend diy multislider using LCD. It will also lower CPU overhead

Have you created a DIY LCD-based multislider that you can share?

> ....Moreover multislider doesnt display low values properly. For clear interface I strongly reccomend diy multislider using LCD. It will also lower CPU overhead

On Dec 3, 2007 2:31 AM, itchy  wrote:
>
> ....Moreover multislider doesnt display low values properly. For clear interface I strongly reccomend diy multislider using LCD. It will also lower CPU overhead
>


Couldnt help you now, but I have it somewhere. Something to start with: 

http://maxobjects.com/?v=objects&id_objet=2332&requested=multislider&operateur=AND&id_plateforme=0

Couldnt help you now, but I have it somewhere. Something to start with: http://maxobjects.com/?v=objects&id_objet=2332&requested=multislider&operateur=AND&id_plateforme=0


those sliders were really helpful using them to control effects and pitch. cheers!

has anyone got a good drum roll tool. tried using stutter but im not sure im using it right. 

those sliders were really helpful using them to control effects and pitch. cheers! 

has anyone got a good drum roll tool. tried using stutter but im not sure im using it right. 


I am building a drum machine using preset.

The metro bangs fast 16th to the counter and runs through different tables (that chose notes of the drum) chosen by a gate.

The preset sets the gate, and it will help for more later. My problem is that when i change a preset, my counter is not finished to read the table it actually runs.

I would like to hit a new preset for the next count, and the next setting will be turning on when my counter will be back to 0.

Question about preset:
I am building a drum machine using preset.
The metro bangs fast 16th to the counter and runs through different tables (that chose notes of the drum) chosen by a gate.
The preset sets the gate, and it will help for more later. My problem is that when i change a preset, my counter is not finished to read the table it actually runs.
I would like to hit a new preset for the next count, and the next setting will be turning on when my counter will be back to 0.
How can I program it?


i don't know [preset], but to 'sync' a bang you could experiment with [gate] and [sel]: use your preset change activity (i suppose you click a button or sth like that?) to open the gate, so the bang from [sel 0] (change the arg for any other beat you'd like things to change on) can come through and change your presets.

| lead back to the left inlet of [gate] to close it again

to [preset] or wherever you want it to go to

(sorry, the spaces in above example are not reproduced in the forumformatting it seems.)

[bang  [counter 15]
|        |
[1     [sel 0]
|      /
|     /
[gate]
|
[t b 0]
|    
|    lead back to the left inlet of [gate] to close it again
|
|
to [preset] or wherever you want it to go to

keep your sequencing in the signal domain - infinitely better! seq~ has the advantage of being able to send out any message as well, not just bangs. Also, you can lock sync to any rewire host using hostphasor~.

i've made drum machine things in the past and cant recommend enough doing things in the signal domain (MSP) as opposed to the event world of max.

Also, wherever you're thinking of using the preset object, use pattr also infinitely better!

keep your sequencing in the signal domain - infinitely better! seq~ has the advantage of being able to send out any message as well, not just bangs. Also, you can lock sync to any rewire host using hostphasor~. 

Also, wherever you're thinking of using the preset object, use pattr  also infinitely better!


Seconded. I recently changed an old drum machine patch of mine to be driven

by seq~, (and pattrified it at the same time, strangely enough), and it was

> keep your sequencing in the signal domain - infinitely better! seq~ has the

> advantage of being able to send out any message as well, not just bangs. Also,

> you can lock sync to any rewire host using hostphasor~.

> i've made drum machine things in the past and cant recommend enough doing

> things in the signal domain (MSP) as opposed to the event world of max.

> Also, wherever you're thinking of using the preset object, use pattr also

Seconded. I recently changed an old drum machine patch of mine to be driven
by seq~, (and pattrified it at the same time, strangely enough), and it was
well worth the effort.
Cheers
Roger

>
> my advice:
>
> one word: seq~
>
> keep your sequencing in the signal domain - infinitely better! seq~ has the
> advantage of being able to send out any message as well, not just bangs. Also,
> you can lock sync to any rewire host using hostphasor~.
>
> i've made drum machine things in the past and cant recommend enough doing
> things in the signal domain (MSP) as opposed to the event world of max.
>
> Also, wherever you're thinking of using the preset object, use pattr  also
> infinitely better!

im creating a similar thing and have a problem with the gate function after the pattern has been entered into a matrixctrl. A metro is creating the timing and a gate 16 is splitting the bang into 16 steps except it misses the first bang so it is effectivey 15 steps. That is to say the first beat on the matrixctrl is the second bang out of the gate.

im creating a similar thing and have a problem with the gate function after the pattern has been entered into a matrixctrl.  A metro is creating the timing and a gate 16 is splitting the bang into 16 steps except it misses the first bang so it is effectivey 15  steps.  That is to say the first beat on the matrixctrl is the second bang out of the gate.


don't you have to turn on the gate to get it to advance - from 0 to 1, for example?

Toiletmuck  wrote: 
im creating a similar thing and have a problem with the gate function after the pattern has been entered into a matrixctrl.  A metro is creating the timing and a gate 16 is splitting the bang into 16 steps except it misses the first bang so it is effectivey 15  steps.  That is to say the first beat on the matrixctrl is the second bang out of the gate.


I resolved the prole, and I did use max to play some songs last week.

The thing is you have to use many of the foncions to run the counter thru the gates to make t run properly, But it works!

I'll show you later my patch that is sill un perfect because:

if I try it once it is oen, it wont be workin a secont time on begining,

In Fact, I have to set it up better because max is not a drum machine, but can make it eventually and it can be the most open drum machine ever used

I'll speak english
I resolved the prole, and I did use max to play some songs last week.
It was really stable !
The thing is you have to use many of the foncions to run the counter thru the gates to make t run properly, But it works!
I'll show you later my patch that is sill un perfect because:
if I try it once it is oen, it wont be workin a secont time on begining,
In Fact, I have to set it up better because max is not a drum machine, but can make it eventually and it can be the most open drum machine ever used
Have many children ,
Iv


the problem now appears to be that the first column of sequence comes out as the last, through the gate...

ive just noticed how metro is at keeping time and was looking at using seq~ as suggested but not entirely sure how to use it. any advice?

I recently converted an old drum machine patch to be seq~ driven, for just

this reason. I don't have it with me atm, but I'll try and whittle out the

> ive just noticed how metro is at keeping time and was looking at using seq~ as

> suggested but not entirely sure how to use it. any advice?

I recently converted an old drum machine patch to be seq~ driven, for just
this reason. I don't have it with me atm, but I'll try and whittle out the
appropriate bits and post it tomorrow,
Cheers
Roger

>
> ive just noticed how metro is at keeping time and was looking at using seq~ as
> suggested but not entirely sure how to use it. any advice?
>
> cheers james

It's not sample accurate as it dips into the schedular domain - for sample accurate triggering you want Eric Lyon's el.samm~ etc. - but if you drive a number of these modules from a single master phasor, the timing stays a lot tighter than a metro driven clock.

It's probably more complicated than it needs to be, as it drives other functionality elsewhere in the patch, but it should get you started,

OK, here it is. 
It's not sample accurate as it dips into the schedular domain - for sample accurate triggering you want Eric Lyon's el.samm~ etc. -  but if you drive a number of these modules from a single master phasor, the timing stays a lot tighter than a metro driven clock.
 It's probably more complicated than it needs to be, as it drives other functionality elsewhere in the patch, but it should get you started,
cheers
Roger