Nice idea trying to be better

[pucho812]

Latency is the Achilles heel of digital audio. But this looks cool.

https://www.jacktrip.com/how-it-works

 

[midwayfair]

I think overall it's less the electronic and programming challenges of sending audio with minimal latency and more the fact that my internet is trash and throttles video. :/ I could put up with 10-20ms of delay if I'm internet jamming with someone, it's a lot harder to deal with the tempo constantly changing from buffering or stopping completely because of a hiccup. I even stopped live streaming, I just record concerts and upload them now.

Not trying to be negative, there are probably some people this will work for.

 

[JohnRoberts]

I recall back in the 80s while working at Peavey (sorry another Peavey story), I was tasked with being the inside man on a SMPTE to midi controller product (Synccontroller). The project was brought in by an outside engineer (now RIP) and I use the term engineer loosely. This was an early micro (6511) based smpte time code generator that could lock real machines together (reading time code from a tape track and remotely controlling the tape recorder speed), and locking additional virtual machines together using midi.

To skip over a bunch of painful details, a friend of mine had a local band based around using a drum machine (the name of his band was robodrum and they didn't suck). I used him and his band to test the synccontroller for real world (recording) use. This friend's band had a really good bass player and he would get very angry at the imprecision of the midi timing derived from SMPTE printed to tape.

I couldn't easily confirm the accuracy, but I believe the bass player. The guy who wrote the code was sloppy. I had a technician working almost full time testing the software to identify bugs. Every time he fixed one bug he caused two others. I know this sounds like a bad joke, but sadly it was mostly true and I was stuck in the middle.

JR

 

[pucho812]

I recall back in the 80s while working at Peavey (sorry another Peavey story), I was tasked with being the inside man on a SMPTE to midi controller product (Synccontroller). The project was brought in by an outside engineer (now RIP) and I use the term engineer loosely. This was an early micro (6511) based smpte time code generator that could lock real machines together (reading time code from a tape track and remotely controlling the tape recorder speed), and locking additional virtual machines together using midi.

To skip over a bunch of painful details, a friend of mine had a local band based around using a drum machine (the name of his band was robodrum and they didn't suck). I used him and his band to test the synccontroller for real world (recording) use. This friend's band had a really good bass player and he would get very angry at the imprecision of the midi timing derived from SMPTE printed to tape.

I couldn't easily confirm the accuracy, but I believe the bass player. The guy who wrote the code was sloppy. I had a technician working almost full time testing the software to identify bugs. Every time he fixed one bug he caused two others. I know this sounds like a bad joke, but sadly it was mostly true and I was stuck in the middle.

JR

Fix one thing break two others? Been there done that.

 

[pucho812]

I think overall it's less the electronic and programming challenges of sending audio with minimal latency and more the fact that my internet is trash and throttles video. :/ I could put up with 10-20ms of delay if I'm internet jamming with someone, it's a lot harder to deal with the tempo constantly changing from buffering or stopping completely because of a hiccup. I even stopped live streaming, I just record concerts and upload them now.

Not trying to be negative, there are probably some people this will work for.

Well the tech is getting there. And yes network dependent