Is there a way to hook up JACK port to TAPE REC as well as OUT DAC?

infinitedigits · 2020-11-23T18:29:10.685Z

i’m pretty new to JACK so please forgive if this is a naive question.

what i am trying to do: i want to simultaneously capture the norns audio output while also doing playback of some other audio into the same norns from inside the norns itself (via JACK). the tricky thing is that I don’t want the playback to be present in the capture because this might be for norns<->norns internet audio collaboration and that would cause feedback (because both are capturing their own audio and playing back the other norn’s audio).

i have found that i can use JACK for capturing audio via jack_capture and I can also use JACK for playback by using a mpv server setup to one of the JACK ports.

my question is: are there JACK ports for capturing from TAPE REC, and are there JACK ports for playing back into OUT DAC? this would be ideal, as I could then capture audio and insert audio without feedback. an alternative solution is to just stay mono and capture the L channel and playback in the R channel for instance. (or other alternatives?)

image1372×780 110 KB

as far as i can tell these are the available JACK ports, none of which seem to be able to stream into the OUT-DAC nor get output before the TAPE-REC.

system:capture_1
   crone:input_1
system:capture_2
   crone:input_2
system:playback_1
   crone:output_1
system:playback_2
   crone:output_2
crone:input_1
   system:capture_1
crone:input_2
   system:capture_2
crone:input_3
   softcut:output_1
crone:input_4
   softcut:output_2
crone:input_5
   SuperCollider:out_1
crone:input_6
   SuperCollider:out_2
crone:output_1
   system:playback_1
crone:output_2
   system:playback_2
crone:output_3
   softcut:input_1
crone:output_4
   softcut:input_2
crone:output_5
   SuperCollider:in_1
crone:output_6
   SuperCollider:in_2
softcut:input_1
   crone:output_3
softcut:input_2
   crone:output_4
softcut:output_1
   crone:input_3
softcut:output_2
   crone:input_4
SuperCollider:in_1
   crone:output_5
SuperCollider:in_2
   crone:output_6
SuperCollider:out_1
   crone:input_5
SuperCollider:out_2
   crone:input_6

maybe what i’m suggesting is not compatible with JACK at all . or maybe this idea is just plain loony. in any case, any feedback would be appreciated so i don’t stray onto some weird unproductive path.

zebra · 2020-11-23T23:24:40.410Z

in a word: no.

in that diagram, boxes represent internal busses or processes. JACK ports are represented by circles - solid for output, empty for input. the diagram describes the “mixer” JACK client (named crone to JACK), which has 6 inputs and 6 outputs, connecting the softcut client, the scsynth client (both are 2x2) and the system I/O.

if i correctly understand your intention, i think you need to modify the mixer client. you can pretty easily add a second stereo I/O pair, making it 8x8.

i’ve tried to make this pretty straightforward by using a Client class template which takes an I/O count, and handles the JACK API stuff.

so, MixerClient simply declares that it is 6x6 at class definition time:

github.com

monome/norns/blob/main/crone/src/MixerClient.h#L21


#include "Client.h"
#include "Tape.h"
#include "Utilities.h"
#include "PeakMeter.h"
#include "effects/StereoCompressor.h"
#include "effects/ZitaReverb.h"
namespace  crone {
    class MixerClient: public Client<6, 6> {
    public:
        enum { MaxBufFrames = 2048 };
        typedef enum { SourceAdc=0, SourceCut=1, SourceExt=2 } SourceId;
        typedef enum { SinkDac=0, SinkCut=1, SinkExt=2 } SinkId;
        typedef Bus<2, MaxBufFrames> StereoBus;
    public:
        MixerClient();
        /// FIXME: the "commands" structure shouldn't really be necessary.

then you would want to name your new source/sink by adding to this enum:

github.com

monome/norns/blob/main/crone/src/MixerClient.h#L25-L26


typedef enum { SourceAdc=0, SourceCut=1, SourceExt=2 } SourceId;
typedef enum { SinkDac=0, SinkCut=1, SinkExt=2 } SinkId;

(this just allows you to more usefully index the source and sink busses that are automatically created by the templated parent class.)

and finally you would have to edit the main processing method in MixerClient, probably shuffling some operations around. i guess you’d want to copy to your new sink before mixing in tape playback, then mix from your new source before writing to the DAC sink.

github.com

monome/norns/blob/main/crone/src/MixerClient.cpp#L55


    tape.reader.process(dst, numFrames);
    bus.tape.applyGain(numFrames, smoothLevels.tape);
    bus.ins_in.addFrom(bus.tape, numFrames);
}
processFx(numFrames);
// perform  output
bus.dac_sink.mixTo(sink[SinkId::SinkDac], numFrames, smoothLevels.dac);
bus.cut_sink.copyTo(sink[SinkId::SinkCut], numFrames);
bus.ext_sink.copyTo(sink[SinkId::SinkExt], numFrames);
// process tape record
if (tape.isWriting()) {
    const float *src[2] = {(const float *) bus.dac_sink.buf[0], (const float *) bus.dac_sink.buf[1]};
    tape.writer.process(src, numFrames);
}
// update peak meters
inPeak[0].update(bus.adc_source.buf[0], numFrames);
inPeak[1].update(bus.adc_source.buf[1], numFrames);

zebra · 2020-11-23T23:28:44.785Z

but, hm: if all you want to do is make some audio from mpv come out of the physical norns outputs, then all you need to do is connect mpv to the system:playback ports in JACK. that has nothing to do with the norns software clients.

likewise, you can always make a JACK connection from crone:output_1, _2 (which are normally connected to system:playback) to some other JACK client for capture.

(in other words, maybe things are simpler if you don’t use TAPE.)

infinitedigits · 2020-11-23T23:54:03.612Z

firstly, thank you @zebra! how many times now have you swooped in to straighten me out? its getting to be innumerable. i appreciate your answers so much. they are simultaneously helpful, instructive and educational. for instance, now i think i have a better grasp on how crone functions.

i think you found the heart of my question - all i want to do is make some audio come out of norns outputs while being able to capture audio right before that point. what you mention is a perfect solution - i can simply capture crone:output_1,_2 and then do playback at system:playback_1,_2.

i think i had considered that idea but dropped it when looking at jack_lsp as its output showed me:

...
system:playback_1
   crone:output_1
...
crone:output_1
   system:playback_1
...

which i thought meant that the two were essentially indistinguishable / one was an alias of another.

i’m very excited as i’m pretty sure now i can get this to work for norns<->norns audio so music can be created in a shared experience between any two norns anywhere in the world (without expectations of tempo locking of course).

zebra · 2020-11-24T01:07:20.885Z

well, i appreciate that! but of course you’re welcome - what i’m here for. thank you for asking great questions and being an exemplary contributor to the app ecosystem.

huh yeah, that output is really quite confusing, isn’t it.

for the record: jack_lsp -c lists each connection twice: below the source port (crone:output here), and below the sink port (system:playback here).