<div dir="ltr"><div><div><div><div><div><div>Yes I think the best would be too follow GUI seems to be the most intuitive thing to do.<br><br></div>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.<br><br></div>In the end I see two questions that would sum it up:<br><br></div>What gives the least latency?<br></div>What is the least work to implement?<br><br></div>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 ;) ).<br><br></div>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).<br><div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-24 17:00 GMT+02:00 Len Ovens <span dir="ltr"><<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 24 Jun 2016, Melanie Bernkopf wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would expect it to be from one upwards if a strip is off or somehow inactive i<br>
would expect it to be there but non functional or it behaves like the GUI. Out of<br>
experience if there is a way in a program to present something to the user and<br>
adding another way it is best to stay with what they are used to or in that case<br>
with interfaces everyone counts up because they are used to.<br>
</blockquote>
<br></span>
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).<br>
<br>
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 :)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for sending well technically there would it would be possible to send after<br>
the bank change the current strip settings (maybe as a bulk?) with those strips<br>
not used with a value of zero and then not using them or not updating.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
Any unused strip is zeroed, any unused control in an otherwise active strip (ie. record button on a bus) will be zeroed too.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
interface shows the current settings of that bank. In the OSC specification I saw<br>
that it is possible to send bundles with several osc messages being sent at once<br>
but haven´t had a closer look at that or how to differentiate between bundle and<br>
normal single message.<br>
</blockquote>
<br></span>
The OSC lib takes care of that on the receiving end. It is as iff the messages had been sent individually.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If one is on the right or on the left should not matter. If you move a fader (or<br>
</blockquote>
<br></span>
That is up to the surface designer :)<br>
<br>
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.<br>
<br>
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)<br>
<br>
--<br>
Len Ovens<br>
<a href="http://www.ovenwerks.net" rel="noreferrer" target="_blank">www.ovenwerks.net</a><br>
<br>_______________________________________________<br>
ardour-dev mailing list<br>
<a href="mailto:ardour-dev@lists.ardour.org">ardour-dev@lists.ardour.org</a><br>
<a href="http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org" rel="noreferrer" target="_blank">http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div></div>