as much I can tell there is none for the wide public at least.
there were more than one kind of such charting tickers, during the early (bad old) days, meaning the first XXI century decade, when jackd were instrumental for the development of the early low-latency 2.6 kernel (PREEMPT) and then then voluntary-preemptive move which was the direct ancestor to the now known as real-time kernel patch (PREEMPT_RT).
but that's now history and swept away by the dusty sands of oblivion... :)
anyway, now that we're almost nigh into the third decade, is bad old qjackctl still a thing? I know half of the world still rely on it, but let me humbly ask: is this old piece of junk still worthy?
never mind. You're of course welcome to add a xrun ticker/scrolling chart to qjackctl.
by all means.
although I would rather prefer that these two things happen first and in this order:
1) jackctl API ported to jack1 (as is from jack2 currently);
2) completely rewrite qjackctl to use exclusively this native jackctl API, instead and abstracting the jack1 hocus-pocus unix process juggling and also the infamous jack2 d-bus interface for x sake.
that couple would be neat and get my full stamp of approval and blessing ;)
but don't stop it there, please.
all the above complaints have nothing to do with your proposal.
again, you're welcome and all hands and brains are too.
as much I can tell there is none for the wide public at least.
there were more than one kind of such charting tickers, during the early (bad old) days, meaning the first XXI century decade, when jackd were instrumental for the development of the early low-latency 2.6 kernel (PREEMPT) and then then voluntary-preemptive move which was the direct ancestor to the now known as real-time kernel patch (PREEMPT_RT).
but that's now history and swept away by the dusty sands of oblivion... :)
anyway, now that we're almost nigh into the third decade, is bad old qjackctl still a thing? I know half of the world still rely on it, but let me humbly ask: is this old piece of junk still worthy?
never mind. You're of course welcome to add a xrun ticker/scrolling chart to qjackctl.
by all means.
although I would rather prefer that these two things happen first and in this order:
1) jackctl API ported to jack1 (as is from jack2 currently);
2) completely rewrite qjackctl to use exclusively this native jackctl API, instead and abstracting the jack1 hocus-pocus unix process juggling and also the infamous jack2 d-bus interface for x sake.
that couple would be neat and get my full stamp of approval and blessing ;)
but don't stop it there, please.
all the above complaints have nothing to do with your proposal.
again, you're welcome and all hands and brains are too.
cheers