On Sat, Aug 15, 2015 at 05:14:12PM +0100, Simon SD1 wrote:
>
> > On 15 Aug 2015, at 16:06, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
>
> > 'Delayed' connections (those that create a cycle) can be
> > reverted to normal ones as soon as possible (the current
> > implementation does this only when the entire graph has
> > becomes cycle-free).
>
> The options discussed in 2004 were to revert those connections
> when the entire graph became cycle-free, or never to revert them
> so long as they existed.
Waiting for all cycles (if there were ever more than one) to be
broken seems IMHO no better than reverting ASAP. In both cases
the changes are probably not anticipated by the user. My personal
preference would be to never revert such connections.
> The rationale for never reverting them was that a pair of connected
> clients would suddenly be running in a different order — and a buffer’s
> worth of data between them would vanish
But that can happen anyway in Jack1 if a cycle is skipped.
> The rationale for reverting them was lower latency, and to prevent
> pathological cases where a chain of clients could be running in entirely
> the wrong order because of cycles that used to exist but don’t any more.
Seems rather unlikely. If such things are a real problem, then the clean
solution is to make things explicit to the user, but this requires a
change of the API: when a connection is made, you could have the options
- don't care (default), but return result,
- must be normal, fail if not possible,
- must be delayed, fail if not possible.
I've done this in a multithreaded single-process framework (for
things like softsynths, mixers, etc.) It allows to set up feedback
connections in a controlled way.
With the algorithm I have in mind, never reverting is the easiest,
doing so ASAP comes next, and reverting only if the result would
be completely cycle free would be the hardest.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hi all,
The Center for Computer Research in Music and Acoustics (CCRMA) at
Stanford University is a multi-disciplinary facility where composers and
researchers work together using computer-based technology both as an
artistic medium and as a research tool
(https://ccrma.stanford.edu/about). We are (still) currently looking for
a great person to help lovingly take care of and feed our servers,
workstations, and multichannel audio setups.
The right person will be working with and helping a diverse community of
interdisciplinary students (ranging from undergrads to DMAs and PhDs,
studying Music, EE, CS, and many other fields), researchers, and faculty
from all over the world. Our computers mostly run GNU/Linux but there
are Macs in the studios and even a couple of Windows machines in the
NeuroMusic lab. We do complex multichannel audio setups in our studios
and for concert diffusion (3D sound in up to 25.8 channels), we maintain
all our own servers and backups, and we package our own software (and
other developers' open source free software) in repositories so that
anyone can install it easily. All this is quite a lot of work and we
need help!
Qualities sought: curious, tenacious, responsible, self-motivated,
tech-savvy, willing to learn, artist- and wizard-compatible, strong team
player who can work independently.
Full details about the job are here:
https://stanfordcareers.stanford.edu/job-search?jobId=66452
-- Fernando
On Mon, Aug 10, 2015 at 04:43:01PM -0400, Paul Davis wrote:
> it provides output indicating the logic decisions that lead to the
> execution order.
I spent most of the day trying to convinve myself that I was
overlooking something. But in the end the conclusion of all
that work is this:
* The algorithm used by Jack1 to determine the order of
* running clients in each cycle is fundamentally flawed.
The reason in mathematical terms is quite simple.
Both the relations 'A feeds B' and its transitive closure
'A feeds B, maybe indirectly' define only a *partial order*
on the set of clients. Now all classical sorting algorithms,
including the merge sort used in this case, assume a *total
order* of the set to be sorted, and may not produce the
correct result if only a partial order is defined.
It's easy to see this in a less abstract way. All classical
sorting algos are designed to reduce the number of compare()
calls. For example, if they find that a == b and a == c
they will in most cases avoid testing b against c, since
under total order it must be true that b == c.
Now if a '0' return from the compare() function does not
mean equality but rather 'not connected' things change.
Using the example above, you *can not* conclude that b
and c are not connected.
So all it takes is a few unconnected clients or two
or more independent chains to increase the probability
that a classical sort algorithm will fail to produce
a correct sequence.
I actually worked out the example I posted yesterday
with pencil and paper, including all the merge sorts.
This produced exactly the results posted. So there
is no bug in the current code, it is just the wrong
algorithm.
To find a linear sequence preserving the order of a
partially ordered set you need what is known as
'topological sorting'. It's usually implemente using
depth-first search (DFS) with post-order output.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
----- Forwarded message from Fons Adriaensen <fons(a)linuxaudio.org> -----
Date: Mon, 10 Aug 2015 19:46:15 +0000
From: Fons Adriaensen <fons(a)linuxaudio.org>
To: Paul Davis <paul(a)linuxaudiosystems.com>
Some new evidence which may be useful. It seems the
problem occurs only if at least one client is running
before zita-*2* and jack_delay are started.
In the logfile added below, the lines between the '----'
are the ouput of some printf() added to jack_rechain_graph().
The name of each client is printed as the list is traversed,
(near to top of the main loop) and a '*' is printed when a
new chain is started.
fons@erc-linux1:~> /usr/bin/jackd -P70 -p1024 -u -dalsa -dhw:UA22,0 -r48000 -p256 -n2
jackd 0.124.1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:UA22,0|hw:UA22,0|256|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 2 periods for playback
------------------------------
------------------------------
# 1. Start Qjackctl
------------------------------
------------------------------
# 2. Start japa
------------------------------
japa
*
------------------------------
# 3. Start zita-j2n
------------------------------
japa
*
zita-j2n
------------------------------
# 4. Start zita-n2j
------------------------------
zita-j2n
*
japa
zita-n2j
------------------------------
# 5. Start jack_delay
------------------------------
zita-n2j
*
japa
zita-j2n
jack_delay
------------------------------
# 6. Connect zita-n2j -> jack_delay
------------------------------
jack_delay
*
zita-j2n
japa
zita-n2j
------------------------------
# This looks already wrong... jack_delay
# can't be first.
# 7. Connect jack_delay -> zita-j2n
------------------------------
zita-n2j
*
japa
jack_delay
zita-j2n
------------------------------
# Correct delay is measured.
# 8. Connect system:capture_1 -> japa_in_1
------------------------------
jack_delay
*
zita-j2n
japa
zita-n2j
------------------------------
# The order of execution is wrong and
# measured delay increases by one period.
# 9. Connect system:capture_2 -> japa_in_2
------------------------------
zita-n2j
*
japa
jack_delay
zita-j2n
------------------------------
# Correct delay measured again.
# 10. Disconnect system:capture_1
------------------------------
jack_delay
*
zita-j2n
japa
zita-n2j
------------------------------
# Wrong again.
# 11. Disconnect system:capture_2
# ------------------------------
zita-n2j
*
japa
jack_delay
zita-j2n
# ------------------------------
# OK
etc. etc.
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
----- End forwarded message -----
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hello all,
I've been testing some new features of zita-njbridge. The test
setup was:
zita-n2j -> jack_delay -> zita-j2n
with the loop closed via the network. The purpose of the test was to
verify the added latency. It produced the expected result - until I
started another (unrelated) Jack app. Suddenly the delay increased
by one period. Stopping the other app had no effect. Restarting it
made the measured delay return to its original value. Then each
time another app (no matter which one) was started or any ports
were connected or disconnected, the delay switched been these two
values.
First I suspected some bug in zita-njbridge - it has some logic to
detect skipped cycles etc. and handle them gracefully. But I found
no error there, and the problem also occured when no cycles were
skipped.
The I let n2j write the jack usecs time at the start of its process()
to shared memory, and j2n read it and print the difference with its
own process() time. This confirmed what I suspected: when the delay
increased, the order of execution of n2j and j2n was reversed.
Note that as far as Jack is concerned there is no loop in the
graph, and hence no ambiguity as to the correct order.
So the conclusion seems that Jack1 is doing something unexpected
each time the graph order is recalculated.
This seems to depend on how many apps or ports are active before
the test is started. When the test apps are the first ones all
seems to be OK.
I could not reproduce the problem with Jack2.
Has anyone noticed similar things ?
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Ahoy!
Stepping up to Summer'15 release frenzy stage scene, in it's fourth and
hopefully last act,
Qtractor 0.7.0 (muon base beta) is out!
Qtractor [1] is an audio/MIDI multi-track sequencer application written
in C++ with the Qt framework [2]. Target platform is Linux, where the
Jack Audio Connection Kit (JACK [3]) for audio and the Advanced Linux
Sound Architecture (ALSA [4]) for MIDI are the main infrastructures to
evolve as a fairly-featured Linux desktop audio workstation GUI,
specially dedicated to the personal home-studio.
As a major highlight to this release, there's the advent of regular MIDI
controllers mapping/assignment to main application menu command actions,
just like normal PC-keyboard shortcuts, is being introduced (cf. main
menu Help/Shortcuts...).
Have a 'hotta' Summer'15 ;)
Enjoy.
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
http://sourceforge.net/projects/qtractor/files
- source tarball:
http://www.rncbc.org/archive/qtractor-0.7.0.tar.gz
- source package (openSUSE 13.2):
http://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.src.rpm
- binary packages (openSUSE 13.2):
http://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.i586.rpmhttp://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.x86_84.rpm
- wiki (help wanted!):
http://sourceforge.net/p/qtractor/wiki/
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor [1] is free, open-source Linux Audio [6] software,
distributed under the terms of the GNU General Public License (GPL [5])
version 2 or later.
Change-log:
- Complete rewrite of Qt4 vs. Qt5 configure builds.
- Revised MIDI Controlllers catch-up algorithm.
- Mixer multi-row layout gets a little bit of a fairness fix.
- Non-continuous MIDI Controllers now have their Hook and Latch options
disabled as those are found not applicable,
- As an alternative to PC-keyboard shortcuts, MIDI controllers are now
also assignable and configurable for any of the main menu command
actions, all from the same old configuration dialog (Help/Shortcuts...).
- Fixed missing Track and Clip sub-menus from Edit/context-menu that
were found AWOL ever since after the Lazy Tachyon beta release (> 0.6.6).
- An off-by-one bar position (as in BBT, bar, beat and ticks) has been
purportedly fixed as long as LV2 Time/Position atom event transfer goes.
- French (fr) translation line to desktop file added (patch by Olivier
Humbert, thanks).
- A new top-level widget window geometry state save and restore
sub-routine is now in effect.
- Improved MIDI clip editor resilience across tempo and time-signature
changes.
- Keyboard shortcuts configuration (Help/Shortcuts...) now lists
complete menu/action path where available.
- Fixed in-flight VST plugin editor (GUI) resizing.
- Added support to LV2UI_portMap extension, found really handy for the
cases where you have multiple plugins with different port configurations
and a single common UI to drive them all (pull request by Hanspeter
Portner aka. ventosus, thanks).
References:
[1] Qtractor - An audio/MIDI multi-track sequencer
http://qtractor.sourceforge.net
[2] Qt framework, C++ class library and tools for
cross-platform application and UI development
http://qt.io/
[3] JACK Audio Connection Kit
http://jackaudio.org
[4] ALSA, Advanced Linux Sound Architecture
http://www.alsa-project.org/
[5] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html
[6] http://linuxaudio.org
See also:
http://www.rncbc.org/drupal/node/917
Enjoy && keep the fun.
--
rncbc aka. Rui Nuno Capela
Hi !
This is is my first post to the list, I hope the topic is appropriate.
I'm an application developer and I've been using RtAudio/RtMidi for
years as cross-platform backend for audio and MIDI.
It never failed to work on me beautifully... until last week.
I've recently installed a raspberry pi 2 with the latest arch linux
distribution available and, for some reason, RtMidi doesn't report
connected interfaces. However, amidi does show them which makes me
think that alsa is properly configured.
[root@piewzei tests]# amidi -l
Dir Device Name
IO hw:1,0,0 MS-20 Controller MIDI 1
[root@piewzei tests]# ./midiprobe
Compiled APIs:
Linux ALSA
Current input API: Linux ALSA
There are 1 MIDI input sources available.
Input Port #1: Midi Through 14:0
Current output API: Linux ALSA
There are 1 MIDI output ports available.
Output Port #1: Midi Through 14:0
I could bother the nice people at McGill but I guess there's something
very specific to my setup and I'd like to debug it myself.
Would anyone have an idea of what could lead to this behavior ?
Thanks for any pointers,
Marc.
--
http://marc-nostromo.com
Hello list,
I just put PyNSMClient 2.0 on my github page.
https://github.com/nilsgey/pynsm2
It is a Non Session Manager Client-Library in one file with no
dependencies except Python3 (and NSMd of course).
It is designed to make it easier for your program to support non
session management.
There is an example file which is a complete program with a PyQt5 GUI
and a JACK noise generator output. Both the example and the lib-file
are documented. Additionally there is a small README.md
License is LGPL.
The client is largely untested and there are some NSM-API features
missing, but it should be easier to use and be more stable than version
1.
Real testing and a proper release will begin once I use my own lib
with Laborejo2 ( in development behind the scenes).
Have a nice day,
Nils
http://www.nilsgey.de
irc: #laborejo on freenode.
