Branch: refs/heads/master
Home: https://github.com/jackaudio/jack1
Commit: 93bc884bb0c1da54fa6ec410848ddc8319b3a9a1
https://github.com/jackaudio/jack1/commit/93bc884bb0c1da54fa6ec410848ddc831…
Author: Hanspeter Portner <dev(a)open-music-kontrollers.ch>
Date: 2016-01-14 (Thu, 14 Jan 2016)
Changed paths:
M drivers/netjack/net_driver.c
Log Message:
-----------
clear unused slave netjack header fields.
As most NetJACK header fields are not set by the slave and thus may
contain anything (which looks weird on the wire), it makes sense to
actively clear the unused fields.
Commit: a3d5a753c1a6b11de76a06a74780d3edfbbfd6b6
https://github.com/jackaudio/jack1/commit/a3d5a753c1a6b11de76a06a74780d3edf…
Author: Paul Davis <paul(a)linuxaudiosystems.com>
Date: 2016-02-11 (Thu, 11 Feb 2016)
Changed paths:
M drivers/netjack/net_driver.c
Log Message:
-----------
Merge pull request #33 from ventosus/netjack_clear_packet_heder
clear unused slave netjack header fields.
Compare: https://github.com/jackaudio/jack1/compare/cb4b719361c2...a3d5a753c1a6
Branch: refs/heads/master
Home: https://github.com/jackaudio/jack1
Commit: 170367221462adf548f6469881c6bae4e504670c
https://github.com/jackaudio/jack1/commit/170367221462adf548f6469881c6bae4e…
Author: Hanspeter Portner <dev(a)open-music-kontrollers.ch>
Date: 2016-01-14 (Thu, 14 Jan 2016)
Changed paths:
M drivers/netjack/netjack_packet.c
Log Message:
-----------
fix 8bit netjack MIDI payload size.
MIDI payload size in 8bit netjack MIDI mode is calculated wrongly
(assumes 16bit sample size).
This bug sits at the decoding end and seems to be without concequences, as the
MIDI payload size in 8bit netjack MIDI mode at the encoding end is done
right and the decoding buffer thus cannot overflow even with a wrongly
calculated MIDI payload size.
Commit: cb4b719361c239658997e736e4bae3552cc669d0
https://github.com/jackaudio/jack1/commit/cb4b719361c239658997e736e4bae3552…
Author: Paul Davis <paul(a)linuxaudiosystems.com>
Date: 2016-02-11 (Thu, 11 Feb 2016)
Changed paths:
M drivers/netjack/netjack_packet.c
Log Message:
-----------
Merge pull request #32 from ventosus/netjack_fix_8bit_midi_payload_size
fix 8bit netjack MIDI payload size.
Compare: https://github.com/jackaudio/jack1/compare/b1fca754142f...cb4b719361c2
Branch: refs/heads/master
Home: https://github.com/jackaudio/jack1
Commit: 6a629716f0f43a5a1e310f9f66035f175702afd5
https://github.com/jackaudio/jack1/commit/6a629716f0f43a5a1e310f9f66035f175…
Author: Hanspeter Portner <dev(a)open-music-kontrollers.ch>
Date: 2015-11-25 (Wed, 25 Nov 2015)
Changed paths:
M jackd/engine.c
M libjack/client.c
Log Message:
-----------
fix garbage keys in JackPropertyChangeCallback.
Issue
-----
JackPropertyChangeCallback returns a carbage key when removing all keys of
a given uuid, e.g. triggered by 'jack_remove_properties(...)'.
Expected
--------
JackPropertyChangeCallback should return a (NULL) key when removing all
keys of a given uuid.
Culprit
-------
'malloc' is called with key_size==0, which MAY NOT return a (NULL) pointer.
Fix
---
Do not call 'malloc' for key_size==0.
Commit: b1fca754142f221313ece84a7b458f8c0261345d
https://github.com/jackaudio/jack1/commit/b1fca754142f221313ece84a7b458f8c0…
Author: Paul Davis <paul(a)linuxaudiosystems.com>
Date: 2016-02-11 (Thu, 11 Feb 2016)
Changed paths:
M jackd/engine.c
M libjack/client.c
Log Message:
-----------
Merge pull request #29 from ventosus/fix_garbage_keys_in_JackPropertyChangeCallback
fix garbage keys in JackPropertyChangeCallback.
Compare: https://github.com/jackaudio/jack1/compare/310e3f99ded0...b1fca754142f
Hi *!
Funny to see the recent activity prompted by Paul's step-down notice.
I'm a bit worried to see this flurry of fundamental design discussions
about putting everything into some magical lib and whatnot.
Client-server thinking is a fundamental prerequisite for keeping one's
sanity when using UNIX (and Mac OS X, for that matter), and it even
benefits Windows users. Client-server architecture is good. It works.
Nothing against automating things, but if your user-friendly application
feels it must spawn a jack server for me, it needs to do all of the
following:
* pop open a notice to the effect that no jack server has been found and
does the user want you to do that for her/him? together with a checkbox
to not ask again and a notice on how to undo the "don't ask again".
* spawn a jackd server and explain to the user how it guessed what
configuration to use and how to change that. also point out to the user
how to see/modify jack connections with jack_lsp/jack_connect (because
they will always be present on any system that has jack) and of course
point to user-friendly tools such as JackPilot, qjackctl, or patchage.
also tell the user how to access jackd error messages.
no votes for implicit magic without being obvious about what's being done.
good example of how not to do magic (no systemd bashing here, plz, it's
just an example!): i use cd ripping tool "asunder" and tell it to log to
/var/log/asunder.log because i suspect hardware failure of a dvdrw
drive. no log ever appears. days later, i look through the system
journal and see that it has incorporated the asunder log messages.
either asunder logs to syslog anyways and hasn't updated its gui to
reflect it (then i don't have a case here), or journald has some magic
to catch any attempt to start a log in /var/log and reroutes it to the
global log. if the latter, then the user-friendly way to do it is to
write a stub /var/log/asunder.log that contains a note as to what has
happened to the log and where the information is to be found. again: no
implicitism without making it obvious what is happening for old people
who still think everything is a file.
i still think the best way to make jack user-friendly is to quickly
educate users how to start a graphical jack config and patching tool,
and then start their app. this is the free software community. unless we
want to make all our hangouts on IRC, mailing lists, and forums
uninhabitable, we MUST NOT DUMB DOWN OUR NEW USERS, and what's worse,
annoy old and experienced ones!
be friendly, yes, by all means. hide the underlying workings from users
and prevent them from understanding them, never.
just my few cents,
Jörn
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
Sometime in the next two weeks, I will find the time to deal with a variety
of pull requests for JACK 1, update some articles on jackaudio.org (notably
FAQ stuff), and do a new release of JACK 1.
This will be my last work on JACK. The time has come for me to step down
from my role as "benign dictator (and jack1 maintainer)". There several
reasons for this:
* most linux distributions use JACK2 as their default, so JACK1's
relevance has diminished. I
still believe JACK1 to be a superior choice from some technical
perspectives, but there is
no doubt that JACK2's integration with dbus and thus its
interoperability with PulseAudio
has made this the safe and simpler choice for Linux.
* I really don't have the time to even think about things related to JACK
these days. It does
any future development a disservice to have me as the bottleneck, which
I effectively am
at the moment.
* Because 110% of my time is spent on Ardour, the fact that Ardour now has
non-JACK
audio/MIDI I/O options has diminished the significance of JACK for my
own work.
* as the years have gone on, although I am still delighted by the
technical quality and
the conception of JACK, I no longer think that it is a particularly good
idea for most users. There
are times when it is useful
I will continue to pay for the hosting of jackaudio.org (even though JACK2
continues to be distributed, managed and communicated about via other
channels), although if someone wanted to migrate this to some other more
communitarian platform, we could look into that.
I would be happy if someone volunteered to step up as maintainer of JACK1.
It would obviously be even better if someone was willing to take the big
leap to JACK3, a version that combines all the best parts of JACK1 and
JACK2, but I think it is more realistic to accept at this point that this
is not going to happen.
If nobody does step up, then there is a good chance that JACK1 will become
officially unmaintained. This isn't of much consequence, because once the
latest pull requests are merged, there won't be any known bugs in the code,
and also because not many people use it anymore. This also means, of
course, that "maintainer" is not much of a task, should someone feel
hesitant about taking it on.
--p
+ jack-devel
pls see question for Paul below.
On Sat, Jan 30, 2016 at 8:48 AM Benjamin Schmaus <benjamin.schmaus(a)gmail.com>
wrote:
> as the years have gone on, although I am still delighted by the technical
> quality and
> the conception of JACK, I no longer think that it is a particularly
> good idea for most users. There
> are times when it is useful
>
> Could you elaborate on this? Curious to know more.
>
> On Sat, Jan 30, 2016 at 8:39 AM Joakim Hernberg <jhernberg(a)alchemy.lu>
> wrote:
>
>> On Sat, 30 Jan 2016 11:13:06 -0500
>> Paul Davis <paul(a)linuxaudiosystems.com> wrote:
>>
>> > This will be my last work on JACK. The time has come for me to step
>> > down from my role as "benign dictator (and jack1 maintainer)". There
>> > several reasons for this:
>>
>> Sorry to hear about that (as a jack1 user). I thank you for all your
>> work and wish you all the best with future endeavors!
>>
>>
>> --
>>
>> Joakim
>> _______________________________________________
>> Jack-Devel mailing list
>> Jack-Devel(a)lists.jackaudio.org
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
>