Bezza

Hi guys, just a quick problem i'm having this object. I'm using a matrixcrl as an interface for a basic 8 channel sequencer. obviously, attached to the matrix is the [unpack 0 0 0 0 0 0 0 0] object.

I have 2 patches that i am trying to combine into 1 patch, they has different paths(?) from the unpack object, one goes to a umenu with percussion instrument selection and then to noteout etc, the other goes to an itable to get note velocites for accenting on each beat in the matrix and then to noteout.

Each patch works fine separately, i.e. just having one of the 'object paths(?)' from each output from the [unpack 0 0 0 0 0 0 0 0] but when i try to combine the instrument select and note velocity by having two patchchords coming from 1 unpack output, and then both goins into noteout, it doesnt work.

Any ideas? I am at a complete lost. Am i breaking any rules anywhere by having 2 objects connected to one unpack out, or do i need to add in other objects?

Forgive me if i have been a bit vague or confusing, i'll try to get some examples up later.

Thanks in advance, any help is greatly appreciated!

problem-with-unpack-object

> Forgive me if i have been a bit vague or confusing, i'll try to get 

Seeing your patch is the only way people are going to be able to give 

> Forgive me if i have been a bit vague or confusing, i'll try to get  
> some examples up later.

Seeing your patch is the only way people are going to be able to give  
really good advice.

Chris Muir
cbm@well.com	
http://www.xfade.com

OK. I don't have my Mac with me right now, i'll get the patches up later.

Ok. So this is my first attempt at a sequencer; this one with percussion instrument select coming from the [unpack] object:

and this is my sequencer with no option for instrument selection, but allows accents on the 'beats' using an itable from the [unpack] object.

Is there any way i can combine both instrument selection and velocity data from the itable from one [unpack] object?

I did try have each one coming off one output of the [unpack] object, but then nothing worked!

If anyone could point me in the right direction, it would be most appreciated.

You don't need to route them sepearately from the [unpack] object, you can just [pack] them together to form a list before to be sent to [makenote]. The patch below shows one way to achieve this. I've also fixed your "SequenceControl" subpatch, you had it counting 33 steps, and now you can set the tempo in quarter-note bpm. You might find it easier to create an abstraction out of the "drum" subpatch I've encapsulated. This would mean you only have to change one file rather than eight.

Also, here's a nicer image file to load in to [matrixctrl] to show the difference between the 4 velocity levels.

Quote: thereishopeforus@hotmail.com wrote on Mon, 08 December 2008 20:30

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

> You don't need to route them sepearately from the [unpack] object, you can just [pack] them together to form a list before to be sent to [makenote]. The patch below shows one way to achieve this. I've also fixed your "SequenceControl" subpatch, you had it counting 33 steps, and now you can set the tempo in quarter-note bpm. You might find it easier to create an abstraction out of the "drum" subpatch I've encapsulated. This would mean you only have to change one file rather than eight.

> Also, here's a nicer image file to load in to [matrixctrl] to show the difference between the 4 velocity levels.

Wow. First of all thank you for the image file, looks much sexier already :-P

Ok. Let me try and understand what you've done; from the unpack, the [sel] object decides whether or not to play the instrument based on the matrix values,as it did in mine original patch, then that gets sent to the itable for note velocity.

After, does the 51 in the [pack 0 51] object correspond to instrument selection before it gets packed and sent to [makenote] so i have 6 set percussion instruments and 2 that can be changed?

I've come across the [zl rev] object a couple of times, but i dont understand why there is the need to reverse the list. Is it so the sequencer plays from L-R?

Again many thanks mate for taking the time out to help me.

Quote: thereishopeforus@hotmail.com wrote on Mon, 08 December 2008 20:30
----------------------------------------------------
> You don't need to route them sepearately from the [unpack] object, you can just [pack] them together to form a list before to be sent to [makenote]. The patch below shows one way to achieve this. I've also fixed your "SequenceControl" subpatch, you had it counting 33 steps, and now you can set the tempo in quarter-note bpm. You might find it easier to create an abstraction out of the "drum" subpatch I've encapsulated. This would mean you only have to change one file rather than eight.
>
> Also, here's a nicer image file to load in to [matrixctrl] to show the difference between the 4 velocity levels.
>
> lh
>
----------------------------------------------------

Wow. First of all thank you for the image file, looks much sexier already :-P 

You're right about the [sel 0], basically if the value is zero the left outlet will bang but it's connected to nothing, all the other values will be passed through. This just stops the drum sounds triggering when you don't want them to.

Then the value goes to the [table] and selects a velocity.

Then it is packed together with a MIDI note value corresponding to the drum sound you want to play. If you look at the [umenu] and [coll] in the subpatch I created you can easily work out which note number triggers which sound.

You now have a list comprised of the velocity and then the MIDI note number, however the [noteout] object accepts lists with the values the other way around, note first then velocity. So you can use [zl rev] to reverse the list.

The reason I didn't swap the two patchcords going into [pack] is because this object is only triggered by the left inlet and we want it triggered by the velocity coming from the [matrixctrl].

I hope that has explained it fully. If not then I will try to help some more.

thereishopeforus, great patch! I couldn't help but join in by adding a couple things that I've found useful with step sequencers: being able to quickly fill patterns on each track, a marker/scrubbing bar, and selections for what values clicking sets. Hope this is useful, it lets you get patterns up and running with a lot fewer clicks, and lets you experiment with polyrhythms easily.

Another nice feature which could be added is a "shift beats left/right" using zl rot on each row, though this would require storing the lists as you work. Can be useful though.

With multi-value matrixctrls like this one, pattr will also allow interpolation between stored slots too---so you can gradually morph (through the volume levels) between different configurations. This is more useful the more matrix states you have.

All makes perfect sense. Excellent, thanks a lot man.

Ah that's even better. The "clickvalue" mesage to [matrixctrl] is very clever, I didn't even know it existed. I think I'm going to continue to tinker with this.

Quote: seejayjames wrote on Mon, 08 December 2008 22:26

> thereishopeforus, great patch! I couldn't help but join in by adding a couple things that I've found useful with step sequencers: being able to quickly fill patterns on each track, a marker/scrubbing bar, and selections for what values clicking sets. Hope this is useful, it lets you get patterns up and running with a lot fewer clicks, and lets you experiment with polyrhythms easily.

Those sliders and click values are very useful indeed.

Is there any way i can colour code the 'quick click' buttons to correspond with my colours on my matrix (without having the values actually on the matrix itsself) or have the colours of the values 0-4 shown in the itable?

Basically, its there an easy way to show potential users what the different colour's relate to?

Quote: seejayjames wrote on Mon, 08 December 2008 22:26
----------------------------------------------------
> thereishopeforus, great patch! I couldn't help but join in by adding a couple things that I've found useful with step sequencers: being able to quickly fill patterns on each track, a marker/scrubbing bar, and selections for what values clicking sets. Hope this is useful, it lets you get patterns up and running with a lot fewer clicks, and lets you experiment with polyrhythms easily.
>
>
> Fun stuff!
>
> --CJ
>
>
>
----------------------------------------------------

Those sliders and click values are very useful indeed. 

The [tab] object is set to be transparent and the coloured backgrounds are individual [panel]s. To show the user which one is currently selected I stored all the colours and the border state in a [coll] and used the [tab] number to query the [coll] and set another [panel] object. You can even use the + 0 1 2 3 4 keys on your keyboard to make a selection.

The [itable] is out and in comes a [multislider] where you can set the colours of individual sliders. The subpatch below simply grabs the slider number and value and sets this into the [table] so you don't have to adjust the rest of your patch. This way you can remove the pointless slider for zero, which has no effect anyway.

Another addition is that when the sequence is paused you can select a new step to start playing from by clicking in the scrub bar at the bottom. I hope you like the modifications.

Another addition is that when the sequence is paused  you can select a new step to start playing from by clicking in the scrub bar at the bottom. I hope you like the modifications.

Not really a response to your question but I looked at your multiple levels of velocity and thought, wouldn't it be nice to be able to quickly set the velocity directly without clicking 4 times for example.

Holding shift and a number between 0 and 4 will set that value when you click the square. Not perfect but just thought you might like it.

problem with [unpack] object.