Netjack pluggin


#41

That makes a lot of sense. Thank you for breaking it down.
Do you know the reason why jackd is not linked with -rpath?


#42

And last question : would there be a way to properly script all of the workflow you described in order to get a proper clean install on Debian ? Or is there a fundamental blockage here ?


#43

In fact I tryed on firefox and the pedals did show, but the mod-slave inputs/outputs didn’t and the mod update icon also was showing the ‘Failed to connect to MOD cloud’ message.

Im not on my linux now, but I remember I had jack on version 1.9.10. Also Im using an ArchLinux. It’s been a long time since a did that experiment but I think it did work without Xruns at the beginning, but I have no idea what changed that :confused:


#44

It makes no sense for Debian to build libraries with rpath…
JACK is only meant to have 1 version installed on the entire system anyway.

If there is, I’m not going to do it myself.
I do everything in my system via packages. For JACK, I have it updated in the KXStudio repos.

@lucastakejame since you’re running archlinux, just get all updates and try again.


#45

Cheers !


#46

Sorry guys, let me understand.

Is it now possible to use the MOD to stream the audio to the PC or the other way round?

In other words: should I plug my guitar in the mod and the headphones in the PC or the opposite? :slight_smile:


#47

Neither.

The headphones must be plugged in the same device as the guitar. On that device, the jackd process is talking to the hardware. On the other device, the jackd process is running as a netjack instance and talks to the jackd process on the other device via the network.

So you can have :

  1. The mod dealing with the hardware, and providing most of the effects processing. The PC is then used either as a sound source (e.g. running a synthesizer, a drum machine like Hydrogen, or playing a track, a video, running a Youtube video via a browser and the correct config for alsa to redirect that sound to jack) or a sound sink (for instance, if you run a recording program such as Ardour or Audacity on the PC). This is the configuration that interests me most and the one which is the most discussed in that thread.

  2. The PC dealing with the hardware : you are using the PCs soundcard instead of the mod’s hardware. In that configuration, the mod is almost only used for processing the effects. The PC does all the rest. Depending on the quality of your hardware, you might prefer that configuration to the other one, since you can just as well record and process your tracks. But in many cases the mod’s hardware would beat your PC’s, especially if you are on the go with just a laptop and no good sound interface attached to it.

I hope this helps.

Other people : please correct me if I forgot important details or got wrong on some points.


#48

Cool.

So, simplifying a lot, you only have one “real soundcard” active, where you input/output analog audio: the MOD or the PC.

But, since you can have the “virtual sound stream” travel though the MOD and the PC, could you for example plug the instrument in the MOD, connect the clean stream with jack to Ardour in order to record the clean sound, then go back to the MOD where you pass through the plugins and listen to the processed output?

This is a configuration I could use to test and record things when I’m not yet 100% sure of the final sound I want.

Of course this setup does not take latency into account, that has to be tested on the field.


#49

Well, to summarize a lot of what has been discussed above :

  1. Things work wayyyyyyyy better if you have a recent version of jack installed on the PC. The versions coming with Debian or derived are not really good enough. If you run on of these systems, you can still build jack though, but it requires a bit of application as stated by @falkTX

  2. Latency : not really noticeable (in terms of delay), even with the stock Debian jack installed. However loads of xruns that create far too many pops in the recorded sound (I am talking about the case where the Mod drives the hardware). The thing is that is that case, at least on my machine, the pace at which jack buffers are being processed by the mod seem to be much to fast compare to what my PC can handle. I have tried using the latest version of jack instead, with hope that the bottleneck was in the network transmission and it did not really help. I still have to try with --opus though, but I don’t have much hope as I recently observed that my (old) laptop is not strong enough to run jackd at that pace on its own (I mean even when not connected to the Duo). I wish I could try on my Desktop but it is currently down.
    @falkTX, I have a question for you on that : could playing with the -l option help on that instance ?


#50

Well, of course I’d use KXStudio, so I’m sure jack would be good enough :wink:

Another question (pardon me but I’m not at all an expert of the matter).

Could it also be possible the opposite “scenario” of what I proposed before?

Use the PC hardware, play the instrument into the PC (or reproduce a pre-recorded track), pass through MOD processing and get back to the PC and record the output in Ardour?


#51

The -l (latency) option adds network latency (as the same says) in order to handle network congestion better.
But your PC still needs to be able to handle the 48000Hz/128 frames.

@Tarrasque73 yes you can do that, but there’s 1 cycle of delayed processing when the audio gets back into the daw or mod.
you have the usual loop of daw -> external gear -> daw, so that’s expected.


#52

Absolutely.

That was the setup proposed by @falkTX originally which prompted me to try and do the opposite.

I think it should work better in terms of quality of the sound obtained as the process is then mostly driven by the PC and that I expect the Mod to deal with whatever is thrown at it easy peasy. The only sad thing is that you are then not using the beautiful hardware of the mod. Now if your PC has got a nice sound interface and you’ve got all the DI boxes and microphone pre-amp at hand already, that should not be much of a problem.

On my side, I really wanted to make the most out of the Duo hardware, especially while on the move since I don’t want to put £££ on an expensive laptop with an expensive sound interface and all the extra stuff. Apart from that solution not working 100% well for me yet, I am still bothered with the noise issue when using a mic (I am looking forward to the change to mainline kernel very much !)


#53

Thanks for answering.

I see that in the wiki you describe the procedure to launch the MOD in master mode and the PC in slave mode.

What would it be the commands to run the MOD as slave and the pc as master?


#54

Of course in most cases I see myself using the MOD as master, but here the word is versatility!

Imagine getting a pre recorded clean track (or even going going to a friend’s place or the studio and plug your MOD in the PC there) and being able to process the sound with your MOD pedalboards…


#55

The reverse is not guaranteed to work correctly.
In MOD you can expect plugins to run at 48000Hz, and usually 128 frames.
Different sample rates have not been tested, and won’t be anyway as the unit has a fixed one.

Also you might run JACK in non power-of-2 buffer sizes. This breaks some plugins, like pitch shifters.

That said, it is possible, and it’s going to be easier with v1.5, but still requires some manual setup everytime (unless you leave it on a single place and never update…).
Ping this thread again in a few days, 1.5-RC1 is coming very soon, then I’ll post the changes needed to make it happen.

Can you assume they have an updated JACK version installed there?


#56

I have read in other threads that most of the mod software could potentially be built and run inside a PC rather on the mod itself.

An ideal thing would be to have someone brave enough to produce ready-to-run mod packages for a bunch of major Linux distros !!! That would suppress the need for ferrying the data across hardware for this sort of post-processing applications. That would also make the development of new pluggins even more straightforward as it cuts the need for cross-compilation at the developer’s level and would also enlarge the Mod community as users not owning the hardware could still be interested in contributing.

Obviously, Debian not supporting recent versions of jack is a problem here. By the way, do you know what their reason is to stick to 1.9.10 ?

EDIT : I know you guys earn your living by selling the hardware, but I think starting using the software first is a great way to get into buying a Mod pedal eventually as the hardware is super good and way better to have and control on stage than a PC.


#57

Pinging as requested, since the RC1 is up :slight_smile:

Can you assume they have an updated JACK version installed there?

If it were for me, yes. :slight_smile: Since I’m the only techie in the group every PC would have KXStudio installed. :slight_smile:

Jokes aside, I admit that using the PC as master would be an edge case, but still, the key word here is versability…


#58

That would be wonderful.

I’d soooo much like to have KXStudio to be the desktop companion of the MOD.


#59

In 1.5, the jack startup stuff is all inside /bin/mod-jackd.
Modify it to start jackd … -d net … to get jackd in the mod as slave.
(leave the stuff after “-d alsa” out, but keep the rest before it)


#61

Hey I updated my laptop’s jackd version to .12 and stuff worked!! I’ve been able to record some stuff with audacity and it goes fine, but sometimes (for a reason I couldn’t figure it out yet) my cpu usage goes to 100% on the UI and stays there… since I’m already doing ssh to mod is there a command to have mod-ui and jackd verbose so I can have any idea of why this happens?

Cheers!

Ps: Also it seems that midi_from_slave won’t receive the midi notes I throw on system:midi_playback_1 (in my computer). Im using VMPK and a2j to get access to vmpk ports on MIDI tab in qjackctl