Digital audio between Axoloti Boards

[jaffasplaffa]

Oh.. Yeah I see now. Thanks

But I'm hot as hell for the digital stream, I'm already building really sophisticated FX setups in my head

Me too

[johannes]

Im now happily patching to Axolotis at the same time, thx fo the tips here! I have them connected via midi, and one as an FX insert via the analog io.
Still I want to have more resolution for some controlls so I'm wondering how to do this:

That multiplexing concept relies on the (unreleased) digital audio link, can't do that over analog audio.
For high resolution over MIDI, I suggest using pitch bend messages.

[MikkelM]

Ohh Yes. A digital audiolink between boards will improve my life quality. Any idea if this will be implemented in a near future?

[Blindsmyth]

If you're on a mac you can open a second instance of axoloti via terminal with this command:
open -n -a /Applications/Axoloti.app

You select boards in each instance and you're ready to go

But I agree this multichannel audio and data thing would open up so much more possibilites

[miketheman]

Would this (driver/license) be of benefit somehow?

www.usb-audio.com

[rudi]

What's the current status of this project?

[vita]

Sorry for picking up an old conversation, but did this idea go any further?
Is the jt/link/audio related to this? I could find no documentation about it.
I would like to use one board as synth and a second one as fx processor and avoid double D/A conversion.

[SmashedTransistors]

As far as I know it does not work yet.
SPI communication is not the only issue here, I think that threads and DACs must be synchronised between boards and that the current firmware is not able to do so...

Such a feature would be a real revolution for the Axoloti

[Blindsmyth]

Yes far as I know the new firmware has priority but I have no clue if this feature will be part of it. It would be indeed revolutionizing and would solve many problems in my current setups

[SmashedTransistors]

I tried to figure out some soft sync of audio with smart buffers and audio interpolation but it is far too complicated and it can get really buggy and messy if we want bidirectionnal communication. I think that hardware sync is the right way.

[Blindsmyth]

I tried to figure out some soft sync of audio with smart buffers and audio interpolation but it is far too complicated and it can get really buggy and messy if we want bidirectionnal communication. I think that hardware sync is the right way.

Ah so you tried the object of johannes? So with bidirectional you mean you could send from one board to the other but not back and forth?

Unfortunately I lack the programming skills to do/implement something like this. But I would be more than happy to test experimental and new aproaches to this, since I consider it a feature that would really bring axoloti to the next level!

[SmashedTransistors]

The issue is not a programming issue.

The problem if the Axoloties are not in sync is that one would generate chunks of samples slightly faster than the other. At some point, there will be too much samples in one direction and too little samples in the other.
Thus, some samples would snap away or a gap would appear, both cases would generate nasty glitches from time to time.

To take account of this drift, some smart software should manage sort of "elastic" buffering. That's not simple and good management and interpolation would eat a lot of CPU.

If hardware sync is possible, there is no more drift and no much less issues.

[Blindsmyth]

The issue is not a programming issue.

The problem if the Axoloties are not in sync is that one would generate chunks of samples slightly faster than the other. At some point, there will be too much samples in one direction and too little samples in the other.
Thus, some samples would snap away or a gap would appear, both cases would generate nasty glitches from time to time.

To take account of this drift, some smart software should manage sort of "elastic" buffering. That's not simple and good management and interpolation would eat a lot of CPU.

If hardware sync is possible, there is no more drift and no much less issues.

Ok I think I understand. So you would need to synchronize the clocks of the boards somehow?

Edit: But what if you would only send audio from one board to the other as send effect for reverb and delay, but you mix the boards externally. I guess beeing a couple of samples behind would end in a delay wich is not such a big problem on spacious effects?

[SmashedTransistors]

Yes, what i called "drift" is an accumulation of delay. The delayed sample stream must be put in memory, a buffer, but as the delay accumulates, the buffered sampled should be bigger and bigger and eventually, you will have to flush it brutally.

A smart buffer would regulate this delay and avoid flush/snap, this is another drawback of this method, this small delay is called latency.

[Blindsmyth]

Ok this is a good lesson on digital audio I think, thanks!

A smart buffer would regulate this delay and avoid flush/snap, this is another drawback of this method, this small delay is called latency.

So this is what you very starting to implement? And you smart buffer was stilly glitchy and ate lots of cpu?

[SmashedTransistors]

I just started to think about it on paper. Another issue is that proper experimentation and tests would be quite a challenge. I still think that an official/firmware implementation is the best solution.

[vita]

I would really love to see that implemented sooner or later ...
it made a lot of fun on the Patchblocks R.I.P

btw @SmashedTransistors is one of your modularted delay rev (matrix) that I wanted to use, the H4 patch ... insane effect indeed!

[SmashedTransistors]

I should write a little tutorial about these matrices and FDN.

[Blindsmyth]

In the meantime everybody that is interested in that feature should post here to show there is viable interest for digital audio between boards

[lokki]

i sure would love and use such a feature!!!!