On 5/8/12, Paul Davis <paul(a)linuxaudiosystems.com> wrote: Yes, I apologize, looking back, the question wasn't very clear. Picture the following scenario. I read the current jack frame (at the beginning of the process cycle, say 'c') and convert it to SMPTE time, the result is hh:mm:ss:n, where n is some frame 'n'. The next time around the process cycle, c+1, the current jack frame has advanced by a number equal to the period size. An SMPTE frame occupies at least 1/30 seconds. If the jack period size is equivalent to more than 1/30 seconds, then SMPTE time at c+1 will have advanced to hh:mm:ss:n+a, where a > 1. Thus, we have, effectively, skipped over the SMPTE frame n+1. My question is whether the preceding is true.

On 5/8/12, Paul Davis <paul(a)linuxaudiosystems.com> wrote: That's what I was afraid of.

On 5/8/12, Robin Gareus <robin(a)gareus.org> wrote: Yes, correct. Yes, exactly, see below. Yeah, I think it's best to work with jack frames as returned by jack_transport_query(). Yes, I'm writing a jack transport to MTC converter for syncing some things. It's embarrassingly infantile code at the moment, but I'm working on it, it's also my first jack program. It displays SMPTE time in a console at the moment. http://sourceforge.net/projects/jackmtc/ I know there's MTC code in xjadeo (and qtractor or some other DAWs, I think), but I want a standalone console tool. Admittedly, I haven't looked at xjadeo code in detail, I'm trying to wrap my head around the concepts first. Thanks.

On Tue, 2012-05-08 at 10:11 -0400, Egor Sanin wrote: Using MTC with different Linux software and different external hardware sometimes doesn't work or only works if one is slave and the other is master, but it won't work vice versa. An issue that also sometimes happened in the 80s without Linux. Anything that will support more reliable MTC and perhaps will make Linux sequencers without audio tracks capable of being a SMPTE slave, is welcome :). It would be nice if we could sync apps and anyway could use loop play. Regards, Ralf

Thank you Paul :) this explains a lot. The Atari ST usually worked good with some equipment here, but IIRC the Prophet Studio 440 didn't work good. I also tested Linux, but I can't remember what exactly worked and what didn't work. Regards, Ralf

On Tue, 2012-05-08 at 11:21 -0400, Paul Davis wrote: Using MTC quarterframe messages uses no more than 240 bytes/second, less than 1/10th of the bandwidth: http://en.wikipedia.org/wiki/MIDI_timecode#Quarter-frame_messages

On Fri, 2012-05-11 at 07:26 +0200, Ralf Mardorf wrote: PS: So if only Quarter Frame is supported, you'll run into trouble, as I often did. As I already pointed out. I experienced that device A can be slave of device B, but device B can't be slave of device A. That's why Paul explained it (to us/me) and he's right.

On Fri, 2012-05-11 at 10:24 +0200, Jens M Andreasen wrote: For the last days I was to much in the Internet, so I won't attach a long list and btw., I don't remember exactly all machines and won't test it now. However, some of the no-name-crap comes from Dave Smith. "MIDI Time Code In addition, the Studio 440 is the first sampler or sequencer to incorporate the new MIDI Time Code, a protocol that encodes SMPTE and sends it over MIDI for use in cue or event lists. Now it is possible to cue punch in/punch out recording by bar number, or with sub frame resolution by programming to SMPTE Time Code. You can even selectively pre trigger external synthesizers to compensate for their internal timing delays. The Studio 440's capabilities will be further enhanced when used in conjunction with forthcoming librarian, editing, and post production software packages by companies such as Digidesign, Hybrid Arts, Dr. T's Music Software, and Opcode." - http://siliciumalpha.chez.com/Analog/studio-440/studio-440-infos.htm If you should own this crap, please give it to me. I don't own it, just a friend does. http://www.linux-archive.org/64-studio-user/178162-ultimate-mtc-test-take-1… - Ralf

On Friday, May 11, 2012 09:17:37 AM Jens M Andreasen did opine: I think I'll have to agree with Jens here. If the hardware can't do it, put it someplace it can do something useful, door stop or window prop as needed. Since I'm involved with a totally different area that is also _extremely_ sensitive to real time, absolutely on time performance, metalworking machine tools that position the cutting tools with stepper motors, as a field we tend to gravitate to what works, with IRQ latency being nearly the sole judge of what works and what works poorly or not at all. The machine we've found to be the current best of the crop is one that is dirt cheap, I've bought 2 of them so far for about $250 USD ea. Complete shoeboxes, decent sized hard drives, 2Gb of memory, onboard video, even a good parport for our uses, a true set the bios, load up the software and go box. The magic ingredient is an Intel D525MW motherboard, carrying a passively cooled, 1.6 Ghz dual core Atom cpu. We disable hyperthreading as its a time waster of legendary proportions, boot an RTAI enabled kernel, using the isolcpus=1 command, so the non-real time stuff runs on core0, and the real time on core1. Typical latency test figures are in the 2.5 u-s range and we run the base-thread at 25 u-s between loops, or 40 kilohertz. Using motor drivers that microstep the motors by doing a /4 or /8, even a /16, the motors can be turned quite a few hundred rpms. These motors need a steady heartbeat to do that, and a poor machine will limit motor speeds by missing a step, causing the motor to slow or even stop and when this poor machine finally does get around to issuing more steps, the motor is slowed or stopped and cannot accelerate back to full speed so it loses a step and stalls. A hung motor and likely a wrecked part because the motor on a different axis didn't stop. I don't see why the same, absolutely on time criteria for good performance wouldn't apply to the audio processing and scheduling needed to perform fantastically well for audio. And its not a one trick pony either, I can carve steel on my milling machine while editing the next bit of code in another window, with an IRC client logged into 4 channels, plus a copy of firefox running so I can check out links that might be posted on one of the irc channels, and do it without bothering the milling machines progress. So I have to agree with Jens, if the hardware cannot or won't do it, find hardware that will and use that one for something else or recycle it. And, when you do find something that Just Works(TM) for your use like the Intel D525MW board kits do for us, be sure and publish it here as that will drive sales for the unit, telling the maker he has done something right because there has been a visible uptick in sales. Basically if you want good hardware that does work, tell the world what does, and does not, work. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> Whatever you may be sure of, be sure of this: that you are dreadfully like other people. -- James Russell Lowell, "My Study Windows"

On Fri, 2012-05-11 at 10:01 -0400, gene heskett wrote: The bandwidth here isn't an issue, I don't care about (technical specifications regarding to) this, but some equipment was standard for pro audio studios and it would be nice to be able to use it today (while it already wasn't easy to use it in the 80s too). There're three ways to handle MTC and the quarter way is just one way to go. If you've good luck, you even don't need a pre-roll (loop play can be possible, but usually it isn't), but in the worst case equipment A can't be used with equipment B, so MTC isn't reliable in real live, even if there's enough bandwidth. I anyway did and do use dedicated MIDI IOs, I didn't refer to the bandwidth, but to the fact that respectable brands failed, because many vendors handled MTC in different ways. Equipment from e.g. Dave Smith shouldn't be used as doorstopper. I don't care e.g. about my Yamaha RX21. I mentioned that it would be nice to have perfect MTC and Paul explained that there can't be perfect MTC. - Ralf

On Thu, May 10, 2012 at 10:32 PM, Jens M Andreasen &lt;jens.andreasen(a)comhem.se&gt; wrote: i fully retract my statement. i totally misremembered the quote from the MTC spec, and didn't redo the math. I think my memory was led astray by the comment in the spec "Also, in the typical MTC systems we have imagined it would be rare that normal MIDI and MTC would share the same MIDI bus at the same time". But you're absolutely right, it uses less than 10% of the bandwidth and I was totally wrong about this.

On 05/08/2012 05:24 PM, Fons Adriaensen wrote: thanks for this explanation. robin