Re: Banking on a surface

Yes I think the best would be too follow GUI seems to be the most intuitive
thing to do.

Yes bundles might bring in a bit of latency but I suspect that in the case
of a bank change it would be OK or less than surface setting everything to
zero and waiting for updates. Anyways a bit of latency is allways there and
at work we once traced out the difference between 10M 100M 1G 10G networks
an their latency it was quite surprising to see that they are in that way
all the same. what makes a big difference is UDP and TCP the later being a
bit slower ( but possible to bring to the same speed with deep kernel
hacks). In the end well 10M is not up to date 100M is okay for a control
Surface I think 1G being better but either expensive or using strange
standards.

In the end I see two questions that would sum it up:

What gives the least latency?
What is the least work to implement?

Second question is maybe more important because it is the same amount of
data to be transfered which leaves the main source of latency to the
Microcontroller in the surface and how fast it can handle things (again up
to the surface designer ;) ).

Long Text again but the conclusion would be if it is working allready leave
it that way and when the GUI is not messing things up arange it in a
similar way for not confusing people. But you should also decide where to
draw the line of what ardour is doing and what is better to be done on the
surface or app. If banksize is set just send that amount of strips if not
set send all and leave it to the other side to deal with it (sounds quite
rude but that would be the line I would draw on that matter).

2016-06-24 17:00 GMT+02:00 Len Ovens <[email protected]>:

> 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
>
>

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