Matrix choices

[LuCsa]

Hello!

I find myself in a paralysis caused by ... options and this is my pitiful little cry for help. 😃
My modest template is about to evolve, yet some evolutionary steps are still unclear.
I am using the special editions.

Essentially, I want to use time stretching on some samples (e.g. stac --> staccatissimo, portamento lengths, ...) and slot-x-fade to combine samples like different shorts, or long+short for more attack etc.

I'm unsure whether to build a single matrix with keyswitch/mod wheel navigation or multiple matrices like short, long, trm etc. Or even one matrix per basic articulation like staccato matrix containing stretches, combinations...

How are you or have you been dealing with these questions? What are your experiences and which solutions do fit your workflow (which is....) best and why?

 

Kind regards,
Lukas

 

PS.: I couldn't really find such a thread via the search function...so bear with me, please, if I missed it...

[PaoloT]

Actually, this matter has been discussed several times in the forum. And I guess will continue to be discussed for long.

I can only offer my humble experience. At first, starting with the SE collection, I used a single matrix to host all the articulation I needed for an instrument. This matrix was based on the Basic one supplied by VSL, even if heavily modified to suit my taste.

With the Full libraries, this was no longer possible. I had to go with a single preset for each instrument. Inside the preset separate categories of articulations were collected into separate matrices. For example, I have a matrix for sustains, one for legatos, one for staccato, another for détachés/portatos, and then portamento/glissando, trills, performance repetitions, recorded repetitions…

Most matrices are organized by sub-categories: each column corresponding to type of timbre. I have vib, n.v., molto vib., more/less vib, sul pont, sul tasto, heavy/harsh, harmonics, heavies, lightes/mute basic, fx.

Matrices contain several rows. In some cases (sustains, legatos…) these are selected by playing speed. In some other cases by velocity (fp/sfz/sffz). In other cases, the matrix is a collection of options that are selected by MIDI messages (trill min2, maj2, min3, maj3…).

A huge amount of data. But by following a fixed map, I can easily create the basis of other instruments starting from a template, and can use a single Articulation Set/Expression Map to select the right articulation in each instrument.

Paolo

[civilization 3]

I have certain basic notions of it, like one for shorts, one for performance legato and marcato, one for repetitiions.

But I might just build them ad hoc according to what I need. Not that they'd be incoherent but I'll end up with a 'shorts and dynamics' in two rows with CC1 to get the second row in matrix 2 while 1 is Performance legato +_ marcato. The thing is with me, I don't like to have a preset with a lot of stuff disabled (w. 10-12 cells, you know), I don't do 'whole' type of templates at any level, each piece is rather different, not generic.

[LuCsa]

https://forum.vsl.co.at/topic/30313/Speedy Template Tips/194196

[LuCsa]

@civilization 3 said:

I have certain basic notions of it, like one for shorts, one for performance legato and marcato, one for repetitiions.

But I might just build them ad hoc according to what I need. Not that they'd be incoherent but I'll end up with a 'shorts and dynamics' in two rows with CC1 to get the second row in matrix 2 while 1 is Performance legato +_ marcato. The thing is with me, I don't like to have a preset with a lot of stuff disabled (w. 10-12 cells, you know), I don't do 'whole' type of templates at any level, each piece is rather different, not generic.

Interesting approach! But doesn't that end up in a lot of redundant work? And at the cost of certain advantages like compatibility among instruments etc.?

I do plan do have a "custom piece matrix", though, housing the patches created for a piece specifically...
Or if I go for the multi matrices approach, these could be added as additional rows...

[PaoloT]

@LuCsa said:

@SE: Did you use time-stretched patches and the like in your SE single matrix era?
@multi matrices: How do you navigate between matrices and columns? Both key-switches?

With SE I used a separate matrix to use time-stretched data. With the current system, I reserved from start cells for time-stretched data.

I select matrices with Program Change messages. Inside the matrices, the X-axis is always a Keyswitch. Y-axis can be controlled by speed (to select slow or fast legato, for example); but it can also be controlled by Keyswitch Velocity, when I want to select a particular cell in a column. Also, it can be Velocity, when different dynamics articulations are involved (like fp for the lower velocity, sfz for the middle, sffz for the higest).

Unfortunately, a bug makes Keyswitch Velocity not always viable. When it is, it is a great way to save message counts.

Paolo

[civilization 3]

Whether it's additional (prob not redundant, not if I save the matrix) work or not, I don't necessarily agree with the default layout (I like non-vibrato as more primary) so I would tend to need to roll my own anyway.

It's not anything to model yours after. :D

[LuCsa]

@PaoloT said:

I select matrices with Program Change messages. Inside the matrices, the X-axis is always a Keyswitch. Y-axis can be controlled by speed (to select slow or fast legato, for example); but it can also be controlled by Keyswitch Velocity, when I want to select a particular cell in a column. Also, it can be Velocity, when different dynamics articulations are involved (like fp for the lower velocity, sfz for the middle, sffz for the higest).

Unfortunately, a bug makes Keyswitch Velocity not always viable. When it is, it is a great way to save message counts.

Thanks for the insight. 😊
I think, I just need to start tinkering... (How much I hate to start working without a plan I'm totally sure about, haha.)

@civilizazion_3: Thanks for the warning. 😛