Re: [Traverso-devel] Does Traverso work on non Linux OS's ?

[Remon Sijrier]

>> But if you like to see Traverso working and usable on Windows too, let
>> me
>> know please! (and patches are accepted ;-) )
>
> I strongly advocate a Windows port of Traverso. This may sound odd,

Wow, that indeed sound very odd ;-)

> because I'm a hardcore linux fan ;-) but from the users point of view it
> would be very convenient. I always maintain Windows and OS X ports of my
> applications, and I try to keep them as up-to-date and feature-rich as the
> linux version, although I hardly use them myself. In my experience, most
> users start using my programs on Windows or OS X and are positively
> surprised to find them working on linux as well, once they consider a
> switch. So if the effort is justifiable, let's do it.

Gettting it to work (after sorting out the hold problems) isn't very hard
at the moment.
The plugin support for Windows could be a problem, but apart from that,
Traverso mainly relies on libraries that are multiplatform.

There are I think 2 problems.
One is decent support for the audio driver, currently Jack and ALSA are
supported, and through Jack also the CoreAudio driver on Mac OS X.
There are some plans (don't know the state of it) to have ASIO support for
Jack, which of course means that Jack would be ported to Windows.
In that case, Traverso will automatically gain decent support for audio
cards on the Windows platform.
If not, and I've to add it myself, well, probably a lot of work with
unknown results.
I myself at least won't gonna use Traverso on Windows. I'm surprised how
well Linux performs in contrast to Windows on a number of fronts.

The other problem is maintainance.
If someone would take that job, that would be great. Specially if he/she
would search for a good way to add audio drivers support for Windows.
(investigate if e.g. PortAudio, RtAudio, native ASIO/other are good canditas)
I would like to help with adding the audio support initially, the
packaging and testing should have to be done by someone else.
It simply takes too much time for the ocasional build on the Windows
platform for me.

If someone would like to offer his/her help, greatly appreciated!


> You mentioned having problems with the mouse grabbing. I have a suggestion
> which may resolve the problem (... or not). For certain [x] actions I
> realised that reaching the edge of the screen with the mouse cursor forces
> me to return to the widget to continue the drag (e.g. for very long
> fades). However, if the mouse cursor would actually retain it's position
> during the action, there would be no limiting factor. In that case, the
> cursor would not move out of the widget, and grabbing it would no longer
> be required. So what you would have to do is catch the change in
> coordinates without changing the position of the cursor.
>
> Do you understand what I mean? There are programs acting like this, but I
> can't remember any at the moment. It's probably a 3D software I have in
> mind (would be Lightwave, the only one I know). To move or rotate a scene,
> you click on a button and move the mouse, but the cursor stays on the
> button all the time. Not only is the motion not limited by the screen, but
> the cursor is at the same place you placed it once you stop the action.
>
> What do you think of that?

Would be an option for certain hold actions indeed!
But for the [ D ] action it could impose a problem....?
I'll review the part of the code dealing with this, and see if it can be
done the way you described without making [ D ] like actions a crime to
implement...

Just popping up on my mind, could it be helpfull to not move the mouse,
but instead showing an (animated) cursor which indicates the direction of
the mouse ?
Not sure if it makes sense, but for example gain or fade hold actions
don't have a clear relation to the mouse cursors position, but have one
with the direction of move....


Thanks,

Remon