problems using the tranzport device

problems using the tranzport device
svn revision 1564):

the scroll whell doesnt work properly in transport mode, but it also doesn’t work as I try to change the track volume with it. If I use the wheel to fast, it breakes my connection, so I have to go to the computer and reconnect by pressing the transceiver button a few times.

Is there anything I can do, to help you, to improve the tranzport control?

(Cubase and tranzport are working well, so I think, its not a hardware problem?)

Gerald

Oh - my email was false - here’s the correct one: g.flossmann(at)web.de

sorry - hope to better hear from you now :slight_smile:

Gerald

I have similar stability problems with the tranzport device:

  • I often have to press the buttons twice or more to get playback started or stopped.
  • When changing to the first track and press the track left arrow again, ardour hangs up.
  • I don’t understand the time display on the tranzport. It sometimes shows some sort of TimeCode, sometimes there are Bars|Beats ? - Is there a way to have minutes:seconds displayed?

Best regards
Sebastian

I am delighted to see a few more people using the tranzport, and also sorry that you are both having such trouble.

The problem with rapid movements of the shuttle wheel causing disconnects is presently well known. Basically, that generates too many interrupts for the current userspace driver to keep up with. (There are some things you can do to reduce the problem; I get to those in a second)

It’s not a solvable problem with the current architecture of the ardour interface, either. Ardour2 is basically using a single read/process/write loop, rather than threads for each. The symptom of having to press buttons twice is also an artifact of the single process loop.

Soo… for the past 2 months or so, in my spare time, I’ve been working on a threaded architecture, as well as Linux kernel drivers for both the tranzport and alphatrack.

Are you both using Linux? For linux, the kernel based driver for the tranzport is basically operational. It’s incredibly efficient. It never misses a keystroke or drops a wheel movement, and eats almost 0 cpu. It could use a smarter write buffer, and a less ad-hoc API - but that’s about it.

Unfortunately, the ardour2 component that interfaces to the kernel component is “not quite ready”, and even when ready, won’t work on the Mac until I get the midi interface done, which is after I get linux done…

If you would like to leap in and help in any way… I think there’s less than a week of solid effort required to solidify the tranzport interfaces for linux. I don’t have a “solid” week available, so it’s going to take longer if I keep at it alone. I’m readily available as mtaht4 on the irc.freenode.org as well as on the ardour channel.

In response to your other questions:

Re: Timecode - Presently the system displays Bars/Beats by default. When stopped, it shows a full beat display. When running, it shows a smaller one, so the meter can be bigger (and I/O can be less). Changing it to do minutes:seconds instead is a one line change in the code and a recompile… (yes, at one point soon it will be configurable) - basically change the show_bbt call to show_smpte inside of show_transport_time in lib/surfaces/tranzport/show.cc.

Re: What do you mean by “ardour hangs up”?

Re: Scrollwheel issues

There are some ways to alleviate, (not eliminate) the scrollwheel problem with the current code.

Run the usb interrupt at a high real time priority - lower than jack, and the audio interface, but higher than most everything else. For example, on my system
jack runs at 87, the usb interrupt runs at 86. If you have the tranzport on it’s own usb port, you can actually run the rt priority above jack.

Go gently on it. In many modes you don’t have to move the wheel very far to do something, speed up or slow down.

This problem is the #1 problem affecting the tranzport and it drives me bats, too, so it WILL BE FIXED… everytime I get frustrated I just spin the tranzport’s wheel madly on the box with the kernel driver, and say… “one day…”

re: yes I use linux, and I’ve tried the kerneldriver already - have to say it worked perfectly for about 5 minutes of permanent wheel and knob changing on very high speed - no hang and no lost connection! (I used tranzport_test.sh"

How can I help you to get this into ardour? - you can mail me directly: g.flossmann(at)web.de

regards - Gerald

Hi mtaht, nice to hear you are working on the device support. I’m using debian linux on both the recording-PC and my laptop where I sometimes do the audio arrangement. I will be back from a recording trip in one week and can continue testing the tranzport device then. You can send me an e-mail at mail(-at-)sebastian-arnold.net and hope I can help you in any way to get the support stable.

Sebastian

I got this via email from gflossman, thought I’d document it here.

Hi Mike,

I did some testing and wrote a testreport. Voila - here it is:

Ardour2 and Frontier Tranzport - Testresults

  1. march 2007

Current Version:
ardour2 svn rev. 1640

  1. startmessages

    ardour: [INFO]: looking for control protocols in
    /home/ardour/.ardour2/surfaces/:/usr/lib64/ardour2/surfaces/
    ardour: [INFO]: Control surface protocol discovered: “Generic MIDI”
    ardour: [INFO]: Control surface protocol discovered: “Tranzport”
    ardour: [INFO]: Control protocol Mackie not usable

    Tranzport: cannot configure USB interface
    TranzportControlProtocol::set_state: active 1

but tranzport works as expected

  1. bugs or unexpected - using the device
  • can’t select the last track with track buttons (I create a dummy track as
    a workaround, but that’s not fine)

  • often the tranzport simply stops working, especially if I’m to fast on
    pressing the tranzport buttons
    + sometimes I can reconnect by pressing the transceiver button, but
    most I have to restart ardour
    + if I try to disable tranzport at the menu, ardour crashes

  • if battery is pressed and after returning to normal operation the display
    doesn’t show all informations

  • rewind button doesnt work anymore, if the end position was reached, but
    SHIFTrewind works well

  • on some functions the display shows very crackled, because of unerased old
    characters

  • play, fastforward -> counter display shifts, but forgot the first digits

  • if undo or SHIFT UNDO is pressed, ardour hangs

  • if in fastforward or fastrewind mode, play button don’t plays from current
    position, but jumps back to first pos.

  • button functions not working as described in the manual:
    + SHIFT REC and SHIFT MUTE doesn’t work (nothing happens)
    + SHIFT PLAY does’nt save
    + IN and OUT works as described for SHIFT IN and SHIFT OUT
    + SHIFT SHUTTLE doesn’t work in Master or Pan Mode (SHIFT LOOP)

  1. Featurerequests

It would be very useful if:

  • changing track on tranzport changes the active track on ardour (good for
    viewing the mixer panel of the active track)

  • Shift Add would delete the actual marker, if the cursor is at a marker
    position

Hope, this helps a little bit :slight_smile:

regards - Gerald

Hi mtaht,

I now tested this issue on another machine (debian testing) and latest svn, and got the same result:

If I select the topmost track (normally “master”) and then press the track left key on Tranzport the complete system freezes. All I can do is reset the machine.

anything new on tranzport control?

I’ve been out for a couple of weeks, so I’d like to know, if there has been some development on the frontier tranzport device interface? If not, I don’t have to play around with it and will be patient for another while :slight_smile:

Regards - Gerald

Regrettably I have been extremely busy since the 2.0 release.

I made a fundamental decision to incorporate full midi functionality into the kernel drivers, which is going to take some effort.

Also, I sold my house, and am moving (saturday!), at least temporarily, to Nicaragua.

I hope, once settled in there and after having picked up a little spanish, I’ll be able to spend quite a bit more time on free software.

This is assuming my “offshoring myself” strategy works well enough to pay the bills there, and my laptop handles the heat, and I don’t become enamored with rum and surfing, and I don’t get called back to work in SF.

We’ll see. I’m not taking the tranzport or the alphatrack with me (at least not on the first jaunt), but am carrying the spec(s).