Display speed

[moris]

In 2016, we can display millions of polygones with shadows, lighting, etc in a 3d world @60fps and 30ms in multiplayer games on internet.
Or bank up/down, hide, delete, add, scroll 24 motorized faders almost instantly but we can't via Ghz powered processors: why?
I like this touch fader thing but the responsivness that should be its strength is actually is biggest weakness. That should be miles faster than hardware.
How could we improve that?

[DT_bettinzana]

In 2016, we can display millions of polygones with shadows, lighting, etc in a 3d world @60fps and 30ms in multiplayer games on internet.
Or bank up/down, hide, delete, add, scroll 24 motorized faders almost instantly but we can't via Ghz powered processors: why?
I like this touch fader thing but the responsivness that should be its strength is actually is biggest weakness. That should be miles faster than hardware.
How could we improve that?

Hello moris,
can you explain better what "responsivness" means in your statement? What are you referring to?

[moris]

Sure,

There is always a delai with resync in dtouch. or a delai when banking up faders. This delai is more important when playback is running.
With hardware, it's faster, almost instant even with cheap HUI controllers and slow motors. And without touch, if I shift-scroll in the mixer, its scrolling really fast and smooth. I can go thru the mix session really fast. Not with dtouch.
A recent update (can't remember which one) improved by a lot the resync time.
What would be awesome is a two-finger horizontal smooth scrolling over faders.

[DT_bettinzana]

Sure,

There is always a delai with resync in dtouch. or a delai when banking up faders. This delai is more important when playback is running.
With hardware, it's faster, almost instant even with cheap HUI controllers and slow motors. And without touch, if I shift-scroll in the mixer, its scrolling really fast and smooth. I can go thru the mix session really fast. Not with dtouch.
A recent update (can't remember which one) improved by a lot the resync time.
What would be awesome is a two-finger horizontal smooth scrolling over faders.

OK, now I understand what you mean.

Let me explain: the big problem with the banking is caused by the fact that DTouch communication with PT is done through HUI protocol.
Unfortunately, HUI protocol banks are multiples of 8, while in your screen you have 22 shown tracks. For this reason, when you hit bank in DTouch, DTouch cannot perform a 24 tracks bank because it would drop over 2 tracks (24 track HUI bank instead of 22 depicted tracks). Instead, we perform multiple banks to show the correct tracks in your screen (it is not easy to be explained and cost to us some efforts during the developent of DTouch).
We know that the major DTouch for Pro Tools competitor has this (huge) problem.
Unfortunately, the "multiple" banking delay is caused by the poor Pro Tools reponse (despite multi-GHz CPU!) over the HUI channel.

The resynch is necessary to perform correct banking, to have first and last bank working buttons and to have an internal tracks database.
Having a tracks database is important to carry a lot of other actions and to perform special macros.

Unfortunately, all these problems are not related to DTouch, but to Pro Tools itself. Since HUI is the only available "public" protocol to control PT, we cannot do better, except some small and rare improvements.
In other words, we have done all what is possible. If we all want to have more, the next step is to contact AVID

[moris]

thanks Silvano,

Yes, im aware of the poor hui implementation in ptools. I have been used to it with hardware controllers (qcon pro + extension).
And I figure what the 8 faders banking system is about.
(with 16faders qcon, only 1 controller flipped the faders for sends... only 1 controller was displaying plugins information... too many functions were partially functioning)
But if I remember correctly, there was no resyncing delai time visible. Obviously there was indeed, but fast enough not to feel interrupted in the workflow. the longest delai was when recalling an entirely different mixer, but adding or removing a fader was instant and didn't seem to call for a full resyncing. (maybe the reason is because of less banks used)
So I have an idea:
If the dtouch mixer is an overlay, could a 2fingers-horizontal-scroll simulate the shift-mousescroll (dtouch then would be a remote for the mouse-scroll: sending the navigation command to the system instead of using pt fader scrolling implementation).
The scrolling in protools is instantaneous, I assume the communication between dtouch and the driver is too. When you scroll via 2fingers, dtouch has both informations, the range of the movement, where the faders are moving and where dtouch has to draw faders.
I guess the difficulty is to translate a multipoint movement into a mouse command instead of a protools command?
Best regards
Nico

PS: and yes, in the videos, the scrolling on the raven seems to be stepped and laggy.

[DT_bettinzana]

thanks Silvano,

Yes, im aware of the poor hui implementation in ptools. I have been used to it with hardware controllers (qcon pro + extension).
And I figure what the 8 faders banking system is about.
(with 16faders qcon, only 1 controller flipped the faders for sends... only 1 controller was displaying plugins information... too many functions were partially functioning)
But if I remember correctly, there was no resyncing delai time visible. Obviously there was indeed, but fast enough not to feel interrupted in the workflow. the longest delai was when recalling an entirely different mixer, but adding or removing a fader was instant and didn't seem to call for a full resyncing. (maybe the reason is because of less banks used)
So I have an idea:
If the dtouch mixer is an overlay, could a 2fingers-horizontal-scroll simulate the shift-mousescroll (dtouch then would be a remote for the mouse-scroll: sending the navigation command to the system instead of using pt fader scrolling implementation).
The scrolling in protools is instantaneous, I assume the communication between dtouch and the driver is too. When you scroll via 2fingers, dtouch has both informations, the range of the movement, where the faders are moving and where dtouch has to draw faders.
I guess the difficulty is to translate a multipoint movement into a mouse command instead of a protools command?
Best regards
Nico

PS: and yes, in the videos, the scrolling on the raven seems to be stepped and laggy.

Hello Nico, you haven't understood my description and this is OK because you don't know how it works.
The problem is not drawing some graphics (we are as good as anybody else), but drawing the correct graphics. In other words we must know where we must draw the fader knobs and this information comes from the HUI.
You are right: the HUI bank is not slow, but as I told before, the HUI bank is large n*8 (where n is the number of the connected MIDI ports); if we must bank of 22 tracks, we cannot bank of 24, but we must do a lot more complex sequence of banking. Trust me: we spent HOURS on this!
We can scroll anything as fast as you want, but we must have the information about the fader position which is communicated after a lot of HUI banks and a lot of time-out timers expiration.

What appears to you as a simple problem, is a lot more complex. Trust me: the current banking speed of DTouch is a miracle.

Why do we have this problems? Because we have an overlay superimposed to the PT mixer. If you want a not integrated mixer, with 4 characters tracks name, with poor metering (7 levels if I remember correctly) and with a lot less features than DTouch, we could write it in 1/100 of the time we spent to write DTouch.

I didn't spoke about the laggy response of the competitor product, but about a bigger problem: on it, you have 22 tracks on the screen and after hitting "bank" it moves of 24 tracks ... dropping 2 tracks. And, another drawback is the 4 characters name of the tracks.

[moris]

Thanks again for taking the time to explain.
And it made appear to me that my 'idea' was maybe useful/possible for scrolling the display of the tracks and keep the overlay aligned.
But I missed the main part of the challenge: multi touching faders via hui banking...and time-outs and buffers coming with...
Nico

[DT_bettinzana]

But I missed the main part of the challenge: multi touching faders via hui banking...and time-outs and buffers coming with...
Nico

Yes Nico, the time consuming part in the code is the wait for all the "banks" to arrive, and, considering that a "packet" of HUI data doesn't have a "termination condition", neither a deterministic arrival time, you must work with time-outs, etc ...