nono,

I agree with you 100%....

Your way is THE way......i just stated a work-around.

I totally agree.

SvK

@Christian Marcussen said:

Well of course there are work arounds. But having 8 instances of violins isent really acceptable, nor is it the intention of VSL.

One instrument, one instance - hence you can load multiple matrices. But in spite of that ability things can still be improved upon, which is the aim of my post. [H]

I agree that there are many improvements that can be made to the player software and from the release of 1.05 it is clear that VSL is listening. I think that the best thing that we can do is keep throwing out suggestions as we think of them.

I think that in the end the instances may well become multitimbral, as that could also cut down on CPU usage. However separate instances has not caused me any problems so far.

I have no intention of using 8 instances per instrument, although I am prepared to use a couple just to cover divisi and the lack of automation for some of the parameters in the GUI.

DG

Christian's suggestion makes a lot of sense to me.

--Jay

@Christian Marcussen said:

Well of course there are work arounds. But having 8 instances of violins isent really acceptable, nor is it the intention of VSL.

One instrument, one instance - hence you can load multiple matrices. But in spite of that ability things can still be improved upon, which is the aim of my post. [H]

This is where we differ.........yes on the surface having one instance per instrument seems nice and neat.......But in the real world, composing and producing this way becomes an absolute nightmare...........you would need (i'm guessing here 30+ key switches per instance)

Changing, moving, cutting, editing regions in the arrange window becomes stifling to the degree, that inspiration turns to tedium.

With 8 instances per Instrument, you can at very least give one glance at the arrange window, and see where everything is .....mind you EVEN with 8 instances, I usually STILL have circa 8 Keyswitches per instrument.


Just my 2 cents.


SvK

Well... the suggestions I have come up with so far are from trying to setup my ultimate matrix for each instrument. In doing so I found these things which I would really like to see changed. So to me atleast, and the way I would use the VI these would all be good changes. But thats whats great about this thing - we can all set it up to are individual liking. Now I'm just giving suggestions to how I think things can be improved.

And yes, it really does seem like VSL are listening. So thats cool. In fact thats one of the great things about them having gone to their own sampler. They (and therfore we) dont have to wait for others to ready the software for their needs.

Gotta love it.

I totally agree with the suggestion. It would be a hugh benefit to be able to assign on a local level controller switches.

Jay

@DG said:

I think that in the end the instances may well become multitimbral, as that could also cut down on CPU usage. However separate instances has not caused me any problems so far.
DG

"So far". But, the rest of the Cube hasn't arrived yet!!

I agree with the need for greater economy of resources. We only have strings and ww 1 at the moment, and yet we are already scrambling to link multiple towers to just make those work-- with all the pros and cons therunto appertaining.

Once all 10 volumes are in the hands of users, MARK MY WORDS-- this economy of usage and the need for capabilities of multitimbrel usage, a better distinction between local and global control, etc., will become all the more critical and indispensable.

If people are finding their systems crapping out with a respectable string section loaded right now, then Himmel, bitte helf uns alles ("Heaven, please help us all") when complex wind, brass and percussion configs are needing to be added down the road... (and soon, I hope). Let's just pray that we won't need two computers per orchestral section!!!

Depending upon how and when VI's drivers are updated, mark my words again-- this site is going to be buzzing ANEW with the same questions about instance capacity, RAM needs, hard drive configs, multi monitor setups, and (I dare assert) double and triple (more?) Mac/PC farm networks. All the old discussions are going to resurface in a whole new light-- meaning, how to get the full orchestra you want rather than any old stock full orchestra that fits onto any old 2-3 GB system.

Please don't consider this post as being pessimistic, but more realistic in nature. I am quite optimisitc about all of this as users continue to offer their most constructive feedback on the forum. I wholly agree that VSL is listening-- and listening carefully. That's why they get our love, respect, and CC#'s!!!!!!!!!!

I'd also like to add into this equation the entire forthcoming Mac-Intel Tower issue as well as the whole Mac OS 10.5 ("Leopard") factor.

We've got as much to look forward to as we do to worry about!

@JWL said:

If people are finding their systems crapping out with a respectable string section loaded right now, then Himmel, bitte helf uns alles ("Heaven, please help us all") when complex wind, brass and percussion configs are needing to be added down the road... (and soon, I hope). Let's just pray that we won't need two computers per orchestral section!!!

However, comparing like for like, if I load the same "templates" as I would in Giga then I can reduce the number of PCs in my farm by 75%. However, when you have all these extra articulations it seems a shame not to use them [:(]

DG

Indeed - I did some calculations. And if I'm not mistaken I will be able to load every single instruments of teh cube on my 5 PC's slaves! I have never been able to do that. As a result I have never had solo trombones, alto flute, contrabasson as part of my template. And thats in spite of loving the sound of these. Now I wil have it all!

Cant wait.... Damn I hope this thing gets released soon!

@Christian Marcussen said:

Indeed - I did some calculations. And if I'm not mistaken I will be able to load every single instruments of teh cube on my 5 PC's slaves!

Five PC Slaves??!! Wow.

Why do I feel that I'm ill-equipped for battle? [:D]

Another thing I would like:

That the keyswitches and controller settings are saved as part of a matrix file, in addition to being part of the project. Lets say I save a matrix with CellXfade set to a specific controller. When I then open a new instance of that matrix I want to retain the controllers I have set.

If I then change some settings and save my project in cubase without resaving the matrix the cubase project should then define the cntrollers I have set.

So in a nutshell when I open a new VI the controllers imbedded in the matrix file should take effect. When opening a project the controllers of the project should take effect.

I knowit sounds really complicated, but its quite simple. Anyone understand what I mean?

I'm just growing really tired of setting all my controller stuff each time I open my matrix!

I have an empty template presetfile where I have set all my controllers.
So if I'm starting a new project I first load this empty preset and after that I'm adding my matrix and patch files.

best
Herb

I have two main templates-- one loaded and one unloaded.

The nice thing about the unloaded template is that there is no waiting for it to instantiate. The loaded template, of course has the caveat of taking a longer time to load, but the payoff is that lots of time is saved on searching for or building matrices from scratch.

My biggest hope is that the Syncrosoft policing software will become more efficient (ie: faster) without compromising its effectiveness.

Christian,

Let me just say AMEN to what you are suggesting. You're on a MUCH higher level of technique with this stuff than I am, but I think I'm thinking like you are when I'm using these instruments....it's all about 1 instance per instrument or section, right...!

Two more suggestions. One I have already mentioned in private to Golem, but here is a little reminder.

1) Instruments with no second cell shouldnt react to cell-crossfade. So if I have used cell crossfade one one patch, and change to another I dont have to worry about crossfading back up. As it is now Cell-crossfade causes no sound to be heard because the player crossfades into nothing.

d) Being able to set in/out points in the mapping control diagram. Here is why: Imagine having a velocity crossfaded patch which I want to automaticaly apply some filter to as I cross fade into the highest velocity. I would do this by setting velocity crossfade and filter to the same slider, but invert the filter. So when fading upwards velocity would go up, filter would go down. And heres the problem. When I fade to maximum velocity, the filter will go to minimum filter meaning NO SOUND. So thats why I would be able to set the end point of the filter to 75 rather than 0. So when I crossfade velocity to maximum, the filter goes downward, but ends at 75. A little commplicated to explain, but it should be really simple to implement.

Food for though. Hope you can use it [:)]

I'll just give this a little bump with an appeal to all users to throw your ideas into the open. How do YOU feel the player could be improved?

@Christian Marcussen said:

I'll just give this a little bump with an appeal to all users to throw your ideas into the open. How do YOU feel the player could be improved?

I'd like a feature that suggests a different approach.

So, you play a line, and the VI says "Wasn't this, or a similar line, used in "Terminator 3"? etc, etc. It could save thousands in damage suits.


OK, Ok, seriously though, that's a great idea about cell crossfading. It should know there is nothing to crossfade to...

Tom

The VI automatically selects keyswitches in the 6th octave for bass instruments
It properbly wont matter by the time you can change this since I will have set up my template. But for new users this would be a really niec feature. I can't tell you how tired I am of changing keyswitches from C1 to C6 for my bass instruments. Especially since most my instruments have 12 horizontal cells [[[:)]]]

A varriant of this would be to allow keyswitch selection via keyboard. This would also be really nice. Just doubleclick/rightclick and then press the key on the keyboard.

Drag and drop cells
This was the first change I mentioned months ago. But I just remembered. It would be nice to grab a cell and then just drag it into another cell. So lets say I have set up cells 1-6 with staccato, staccato short, portato etc. and the find out I would like a new patch as the first patch. Then rather than finding each patch again and moving it one cell to the right I could just take the cell and drag it to its neigbour.
----------

Back to creating templates, and finding ideas for improvement [[[:)]]] [H]

Ps: The one I wrote in a previous post about ignoring cell crossfade for instrumemnts with no patch to crossfade to is a really important fix imho [[[:)]]]
Just hoping it isen't overlooked.

Setting XFade Velocity on a local level - i.e. OFF for short notes, ON for legato

This one I'm finding increasingly important. Would be really nice to not have to worry about both switching articulation and turning velocity xFade ON/OFF

I hope this will be considered.

Big vote for drag and drop cells! That would be really handy.

Also want to just be really annoying and mention, in yet another thread, about pushing the "Please wait, loading data..." into the background, so it doesn't take over my entire machine while I'm waiting for samples to load.

I'm sure more stuff will come to mind...

oh yeah! It would be nice to have the standard behavior of "tab" jumping between text fields. I'm thinking of when I change a bunch of keyswtich values; it would be great to just highlight one, enter the new value, then tab to the next one, etc.

J.