Filtering Matrixctrl Values?
So I am attempting to build a monome-esque sequencer, where matrixctrl displays the beat on which a sample is being played, where each row is the sample and each column is the beat. i am trying to filter through the value dumped out the left inlet of matrixctrl using [zl group 3] to output lists of 3, then unpacking the numbers and using [sel 1] for the last unpacked number to determine whether a cell is on or not. if a cell is on, it then triggers the sample to play (which is determined by the row) and the information from column then determines where the sample will be playing, so i have different arguments for the [line~] connected to play depending on the column number. This might eventually lead to some clicks due to the time discrepnacy between max information and msp information, but i have another plan in case that doesn't work. regardless, my problem right now is that my column + row numbers automatically go to the last value output by zl without playing the fragment of sample i want them to. i just began this patch, so it's far from being complete and is a bit messy due to debugging, but here it is:
As always, much thanks for any help provided.
On May 30, 2008, at 4:17 PM, Kyle Kaplan wrote:
> i am trying to filter through the value dumped out the left inlet of
> matrixctrl using [zl group 3] to output lists of 3, then unpacking
> the numbers and using [sel 1] for the last unpacked number to
> determine whether a cell is on or not.
I didn't look too deeply, but I don't understand how you're getting
the matrix information.
I would use the getcolumn message to matrixctrl, driven from your step
counter, to grab the state of a column, then decode that to determine
what samples to play.
Chris Muir
cbm@well.com
http://www.xfade.com
Hello,
I would personally recommend parsing the matrixctrl output to load a buffer that is referenced in your sequencer (using peek~ or index~). This also gives you the benefit of being able to switch over to signal-based sequencing should you desire sample accuracy. Here is a little snippet from a drum-machine patch I made awhile ago.
AB
chris, i understand what you're saying and have actually already built a pulse sequencer drum machine based on that helpful little patch on your website. what i am trying to do with this drum machine is have it so that the state of the matrix changes as the beats are cycled through. so lets say there's 16 beats in a sample and 16 columns on my sequencer, as the sample cycles through each beat, the enabled cell for that row (since each row corresponds to a sample) moves through the 16 columns. i would like to be able to click any column as the sample is playing and have the sample start on that corresponding column's beat. so if i have 8 samples and 16 beats, imagine an 8x16 matrixctrl with all the enabled cells moving together in sync, but with the possibility to start on different columns for each row, or to have multiple cells moving together in a row.
as for andrew's patch, i don't really see how what it does would help me out for what i am aiming for. would you be able to elaborate a little bit?
On May 31, 2008, at 11:26 AM, Kyle Kaplan wrote:
> i would like to be able to click any column as the sample is playing
> and have the sample start on that corresponding column's beat. so if
> i have 8 samples and 16 beats, imagine an 8x16 matrixctrl with all
> the enabled cells moving together in sync, but with the possibility
> to start on different columns for each row, or to have multiple
> cells moving together in a row.
So if I understand you correctly, all the rows will be clocked at the
same rate, but with the possibility to have different offsets, so that
for example, when row one is on step one, row two might be on step four.
Is that correct?
-C
Chris Muir
cbm@well.com
http://www.xfade.com
Yes, exactly. And if possible, to have it so that a single row can play at multiple offset points. I suppose I could have 32 separate counters, each offset by one and connected to a [prepend getcolumn] object. Then use arguments w/ the enable/disable cell messages to keep the enabled cells moving from left to right at a steady tempo. I will try that tonight or tomorrow and let you know how it goes.
On May 31, 2008, at 8:27 PM, Kyle Kaplan wrote:
> Yes, exactly. And if possible, to have it so that a single row can
> play at multiple offset points. I suppose I could have 32 separate
> counters, each offset by one and connected to a [prepend getcolumn]
> object. Then use arguments w/ the enable/disable cell messages to
> keep the enabled cells moving from left to right at a steady tempo.
> I will try that tonight or tomorrow and let you know how it goes.
Attached is one way to approach this. Because my design changed midway
through, this version is more complicated than it needs to be, but I
didn't want to take the time to simplify it.
-C
Chris Muir
cbm@well.com
http://www.xfade.com
thanks for helping me out with this, chris. however, it seems like the attachment didn't make it onto your post. would you be able to try to attach it again?
On Jun 3, 2008, at 7:47 AM, Kyle Kaplan wrote:
> thanks for helping me out with this, chris. however, it seems like
> the attachment didn't make it onto your post. would you be able to
> try to attach it again?
Ah... another victim of the Mailing List Forum bridge. (I never
remember that)
I put it up on my examples page, as "Monomish." http://www.xfade.com/max/examples
-C
Chris Muir
cbm@well.com
http://www.xfade.com
Looks great chris, much thanks.
This is something of an old topic, but I thought I'd post a pulse sequencer i made using a group of toggles as opposed to matrix control (inspired by looking at the Henke's PX18). It allows for extremely easy offset, direction resetting, and min/max controls. No need for ghost matrices.
Quote: ComfortableInClouds wrote on Tue, 24 June 2008 13:28
----------------------------------------------------
> No need for ghost matrices.
----------------------------------------------------
Well, the "ghost matrix" was only there to allow for easy row offset setting. That could all be removed as long as you are willing to use number boxes to set offsets, as you do in the check-box version.
In your check-box version, there is an off-by-one error, which results in the previous step's data being sent.
Here is a fixed version of your patch, which also includes a slightly more efficient version using select and int instead of all the gates, and a version using multislider, which I think is sort of slick.
looks good chris, thanks for the input and also thanks for catching the one off error. I tend to forget about bang orders :-P (only been using max for almost 2 months).
question (not related to the patch but to the patching style) - i see in your int-sel method that all your int objects have perfectly aligned patch cords leading to the sel 1 object. how exactly did you do this? i use segmented patch cords, and try to line them up, but inevitably some are slightly off, so it looks like one fat patch cord as opposed to a single, sleek cord.
On Jun 24, 2008, at 6:56 PM, Kyle Kaplan wrote:
> i see in your int-sel method that all your int objects have
> perfectly aligned patch cords leading to the sel 1 object. how
> exactly did you do this? i use segmented patch cords, and try to
> line them up, but inevitably some are slightly off, so it looks like
> one fat patch cord as opposed to a single, sleek cord.
If you align the objects first, then when you align patchcords they
will all be on top of each other.
Also, the MaxToolbox is really great for aligning and distributing
things. But it's beta, so save early and often when using it - http://code.google.com/p/maxtoolbox/
-C
Chris Muir
cbm@well.com
http://www.xfade.com
ah, i see. never realized there was an 'align connections' command.
On Jun 25, 2008, at 8:07 AM, Kyle Kaplan wrote:
> ah, i see. never realized there was an 'align connections' command.
Align Connections is new w/ Max 5, and is really cool, but that's not
what I'm talking about.
The normal Align command will square off patchcords, creating the best
fit path that it can calculate.
Just select a patchcord, or group of patchcords, and hit Align to see
what I mean.
-C
Chris Muir
cbm@well.com
http://www.xfade.com
tanx for the sequencer basics here guys!
got me a monome and starting to work out my 1st seq app for it. i have a vague plan which combines the monome for step triggering and my BCR2000 for setting velocity, pitch and duration of steps.
the duration parameter is not the typical midi note duration but the time interval between steps, tweakable for each step individually. so it d be a sort of elastic-timing step sequencer. i m not sure yet whether i could elaborate on the patches above or should start with a different approach. perhaps if i modulate the metro's bpm for every step i can achieve it by adapting the drum1 patch. if i add multiple sequencer tracks each one would need it's own metro.
any thoughts on this?
correction: will need tempo objects instead of the metro
"perhaps if i modulate the metro's bpm for every step i can achieve it by adapting the drum1 patch."
what i might suggest is using Chris' example of a multislider sequencer, but have the multislider range be, say, between 1 and 4. Then have each multislider value correspond to a different duration; i.e. 1=quarter note, 2 = eighth, 3 = 16th, 4 = 32nd. Would post an example, but don't have Max on this computer.
And, I would recommend using metro rather than tempo. Keeps things more straightforward, IMO. Just convert BPM to milliseconds using [expr 60000/$f1] where $f1 is the BPM. Then further divide/multiply this value to give you different subdivisions/superdivisions of the beat.
And unless you're doing something really
exotic with rhythmic subunits, you might
want to take a look at the Global Transport/ITM
stuff in Max 5 - at the very least, the stuff
will all be synced to a single source [the
Global Transport]
...and the student sitting next to me
has reminded me to mention that using
audio rate objects for sync [phasor~
and rate~] will also give you nice
and tight results, and allow for more
exotic rhythms. He's right, of course -
guess I taught the guy well. :-)
tanx for the tips!
got a little prototype running with a multislider variant. the value scales the tempo of a step up or down, middle being neutral. will post if it grows into anything musically useable.
to gregory - all audio units in order to control max objects have to be translated into max (using snapshot, bangs, etc), and thus their timing gets subjected to max variations. Even with this in mind, will a phasor sending out bangs still be more accurate than a metro object on overdrive?
Well, if I were using play~ objects or groove~
objects to handle my audio, I could certainly
stay in the audio domain, couldn't I?
true true :-D