opps, here’s the link http://www.cubinlab.ee.unimelb.edu.au/radclock/doc.php
Sync or Swim
Public Group
Group Activity
-
Bjorn Vayner posted on the forum topic Testing Methods in the group Sync or Swim: 2 months, 3 weeks ago
Any scenario to start with would be great. As long as the tests and results remain readable. The only reason I mention that is because some guy on the Live forum went a little too far in his tests and notes.
He would write pages and pages of "data" and to this day I still have [...] -
owen vallis wrote on the wire of the group Sync or Swim: 2 months, 3 weeks ago
opps, here's the link http://www.cubinlab.ee.unimelb.edu.au/radclock/doc.php
-
owen vallis wrote on the wire of the group Sync or Swim: 2 months, 3 weeks ago
Here is a link to some great papers regarding stable "software" clocks. I really think that before we try to network remote machines together, we should provide a rock solid, and cross platform, internal software clock source. This page has a Kernel patch to achieve this on linux, freeBSD, and OSX. I'm a little nervous [...]
-
Michael Chenetz posted on the forum topic Testing Methods in the group Sync or Swim: 2 months, 3 weeks ago
You have to consider other aspects depending on the MIDI interface. Are the MIDI interfaces USB or serial or some other type of interface?
Do these MIDI interfaces use timing information like LTC? How many devices are connected to the MIDI interface? How much data is being pushed through the aforementioned MIDI device? There are a [...] -
Bjorn Vayner started the forum topic Testing Methods in the group Sync or Swim: 2 months, 3 weeks ago
Anybody have any suggestions how to test the following things:
- How do you measure the latency of your MIDI interface?
- Is CPU usage a factor?
- How do you measure the collective PDC and other latencies?
Many more determining factors to test, but I figure knowing these latencies as fact would be a nice start.
- Bjorn
Recently Active Topics See All →
-
Testing Methods
Any scenario to start with would be great. As long [...]
Group Wire See All →
-
On November 16, 2009 owen vallis said:
-
On November 16, 2009 owen vallis said:
Here is a link to some great papers regarding stable ”software” clocks. I really think that before we try to network remote machines together, we should provide a rock solid, and cross platform, internal software clock source. This page has a Kernel patch to achieve this on linux, freeBSD, and OSX. I’m a little nervous about patching OSX, any advice? An external device providing clock could be sweet, but I think that a cross platform, and internal source would be better if possible…. although that might be a bit of a pipe dream, lol.
-
On November 16, 2009 Peter Kirn said:
Yep, I’m familiar with the rt kernel. And interestingly enough, there’s a Beagle Board project that would support it, in case you don’t want a whole machine for this.
http://beagleboard.org/project/omap-rt-patch/There’s no reason you couldn’t do both MIDI and OSC, it seems to me. You’d want MIDI on the server in case you wanted to connect to hardware. For software connections, you could do OSC and then translate to MIDI on the client.
-
On November 15, 2009 Michael Chenetz said:
Here is a link to one of the implementations of a realtime kernel in Linux. There are actually a few… http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions. My ideas would be to have a serve that basically sends a beacon or signal out every x amount of seconds or milliseconds and everyone can use that signal as a reference in time. So tempo does not become an issue. You can have different tempos and time signatures that are relative to the sync signal. I envision that a device would connect to the server and then the sync would start. We could then write some simple routines that relate BPM to the sync signal. So, if you know to expect the sync signal every x amount of second then maybe bpm would be equal to x/ppq or something like that. The advantage to this method is that it uses a really tight timing mechanism and the BPM and other timing factors can be relative. You could definitely accomplish this really easy with OSC, M4L/PD/Processing/whatever your app is and a little C code on the Linux server. Again these ideas are off of the top of my head. I would really have to sit down and think about some of the variables…
-
On November 13, 2009 owen vallis said:
I also agree with leaving Midi behind when it comes to sync, however, in the interest of being able to sync existing gear, or Ableton Live, it looks like we should at least come up with a Midi based solution as an option. Any info or links to docs about the Linux kernal clock? Sounds interesting