'connecting via jack-connections is a no go situation' *iif* you're connecting ports owned by the very same jack client; depending on its internal processing order you most probably get just silence.
one major issue relates to the zero-copy optimization behavior of jack when only one connection is established on an input buffer port: it just references or points or shunts to the source/output port buffer instead of copying the whole bytes around.
when the input port belongs to the same client owning the connecting output port, then most probably again, you get nothing, zero, nada, dead silence. just because the jack client might process the input buffer *before* clearing and writing to the output buffer, which is perfectly normal on any causal system:)--there, if both buffers are one and the same (zero-copy, remember?) then the input port data just gets lost.
otoh. qtractor is not ardour in any sense (otherwise it would be named after q.i.n.a.;)) btw. have i ever told that it's not a daw.? the sophistication of ardour is well beyond what you might expect from a sequencer like qtractor... oh my...
like most daw's in the world, ardour tends and targets a monolithic, an all-in-wonder model. that meaning, you do everything and the kitchen sink *inside* it. quite the opposite of the jack, at least original prospect, of being the infrastructure of a modular workflow--yeah, qtractor is a hybrid, you can tell that-- nevertheless, linuxaudio history tells you that jack was the original internal audio engine of, yes, no other than ardour indeed, way back on a very early XXI century first decade.
let's try to get a bit technical here... :)
'connecting via jack-connections is a no go situation' *iif* you're connecting ports owned by the very same jack client; depending on its internal processing order you most probably get just silence.
one major issue relates to the zero-copy optimization behavior of jack when only one connection is established on an input buffer port: it just references or points or shunts to the source/output port buffer instead of copying the whole bytes around.
when the input port belongs to the same client owning the connecting output port, then most probably again, you get nothing, zero, nada, dead silence. just because the jack client might process the input buffer *before* clearing and writing to the output buffer, which is perfectly normal on any causal system:)--there, if both buffers are one and the same (zero-copy, remember?) then the input port data just gets lost.
otoh. qtractor is not ardour in any sense (otherwise it would be named after q.i.n.a.;)) btw. have i ever told that it's not a daw.? the sophistication of ardour is well beyond what you might expect from a sequencer like qtractor... oh my...
like most daw's in the world, ardour tends and targets a monolithic, an all-in-wonder model. that meaning, you do everything and the kitchen sink *inside* it. quite the opposite of the jack, at least original prospect, of being the infrastructure of a modular workflow--yeah, qtractor is a hybrid, you can tell that-- nevertheless, linuxaudio history tells you that jack was the original internal audio engine of, yes, no other than ardour indeed, way back on a very early XXI century first decade.
things have changed, as the world itself.
hth.
cheers