Re: Banking on a surface

On Fri, 24 Jun 2016, Melanie Bernkopf wrote:

> I would expect it to be from one upwards if a strip is off or somehow inactive i
> would expect it to be there but non functional or it behaves like the GUI. Out of
> experience if there is a way in a program to present something to the user and
> adding another way it is best to stay with what they are used to or in that case
> with interfaces everyone counts up because they are used to.

So I think you are saying GUI like. In a GUI when we scroll it is by an 
indeterminant amount. I suppose I should allow a touch strip to 
scroll then. (/bank_to <start_strip>) But most people are not going to 
have one and will be doing bank by banksize. Those who what to get all the 
strips and use their own GUI (touchpad) to scroll would set bank size 
infinite (banksize 0).

Those who are banking with bank_up/down would get the most GUI like 
experience with having the top bank remain as full as possible. As 
happens, that is the way things are in OSC just now... because it is easy 
:)

> As for sending well technically there would it would be possible to send after
> the bank change the current strip settings (maybe as a bulk?) with those strips
> not used with a value of zero and then not using them or not updating.

This is already true. They are not sent as bundles... as far as I can tell 
bundles means that the messages are sent in one packet, but are still a 
stream of separate messages. There are some places where I could at least 
bundle up two messages, I will look into that. But general bundling in 
this case would probably add latency as I would have to save up messages 
and bundle them every n usec. Or I would have to duplicate code fo just 
the banking case.

In any case, when banking, the surface is sent all the setting for the new 
bank. Motorized faders should move, buttons lights change, encoders 
indicators change and and display text change.

Any unused strip is zeroed, any unused control in an otherwise active 
strip (ie. record button on a bus) will be zeroed too.

> interface shows the current settings of that bank. In the OSC specification I saw
> that it is possible to send bundles with several osc messages being sent at once
> but haven´t had a closer look at that or how to differentiate between bundle and
> normal single message.

The OSC lib takes care of that on the receiving end. It is as iff the 
messages had been sent individually.

> If one is on the right or on the left should not matter. If you move a fader (or

That is up to the surface designer :)

GUI strip positioning is not right at the moment. (try new session, add 
three audio tracks, three buses and maybe a vca or two. Now add three new 
tracks between the audio tracks and the buses and note the order :) now 
save and reload. note the position of the master track (in the editor) 
before and after. This does affect the ordering on a surface. However, at 
least master/monitor would normally be fixed on a surface at least.

But that is not a surface problem. Selection is not right at the moment 
either. SO long as only one strip is selected it works as expected. But if 
strips are grouped the surface can't select anything but the first strip 
in a group rather than following the editor mixer strip. (MCP code too)

--
Len Ovens
www.ovenwerks.net

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org