Hi, sorry for cross-posting,
I'm wondering which is the current status fpr the rtpMIDI protocol
suppurt under Linux.
As far as I know, there was midistream but is not maintained anymore.
Midistream was merged in a Scenic, but Scenic is a "huge" piece of software.
I need only rtpMIDI support.
There are some other solitions?
It would be nice if rtpMIDI, since it is a sort of stadard, will be
integrated directly in Jack (or ALSA?... humm, i think that rtpMIDI is
more a Jack thing).
What do you think about it?
Cheers
--
a.
Hello everybody!
Qtractor 0.7.5 (hazy photon) is out!
It comes with one top recommendation though: please update, at once,
while it's hot! :)
Highlights for this dot/beta release:
* Overlapping clips cross-fade (NEW)
* MIDI Send/Return and Aux-Send insert plugins (NEW)
* Generic and custom track icons eye-candy (NEW)
Some other interesting points may be found in the blunt and misty
change-log below.
And just in case you missed it before,
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.
Change-log (since last tacky release):
- Beat unit divisor, aka. the denominator or lower numeral in the
time-signature, have now a visible and practical effect over the
time-line, even though the standard MIDI tempo(BPM) is always denoted in
beats as quarter-notes (1/4, crotchet, seminima) per minute.
- Fixed an old hack on LV2 State Files abstract/relative file-path
mapping when saving custom LV2 Presets (after a related issue on Fabla2,
by Harry Van Haaren, thanks).
- Default PC-Keyboard shortcuts may now be erasable and re-assigned (cf.
Help/Shortcuts...).
- New option on the audio/MIDI export dialog, on whether to add/import
the exported result as brand new track(s).
- Introducing brand new track icons property.
- Old Dry/Wet Insert and Aux-send pseudo-plugin parameters are now split
into separate Dry and Wet controls, what else could it possibly be? :)
- Brand new MIDI Insert and Aux-Send pseudo-plugins are now implemented
with very similar semantics as the respective and existing audio
counterparts.
- Implement LV2_STATE__loadDefaultState feature (after pull request by
Hanspeter Portner aka. ventosus, thanks).
- Plug-ins search paths internal logic has been refactored; an
alternative file-name based search is now in effect for LADSPA, DSSI and
VST plug-ins, whenever not found on their original file-path locations
saved in a previous session.
- Finally added this brand new menu Clip/Cross Fade command, aimed on
setting fade-in/out ranges properly, just as far to (auto)cross-fade
consecutive overlapping clips.
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
http://sourceforge.net/projects/qtractor/files
- source tarball:
http://download.sf.net/qtractor/qtractor-0.7.5.tar.gz
- source package (openSUSE Tumbleweed):
http://download.sf.net/qtractor/qtractor-0.7.5-23.rncbc.suse.src.rpm
- binary packages (openSUSE Tumbleweed):
http://download.sf.net/qtractor/qtractor-0.7.5-23.rncbc.suse.i586.rpmhttp://download.sf.net/qtractor/qtractor-0.7.5-23.rncbc.suse.x86_84.rpm
Git repos:
http://git.code.sf.net/p/qtractor/codehttps://github.com/rncbc/qtractor
Wiki (on going, help wanted!):
http://sourceforge.net/p/qtractor/wiki/
Weblog (on going, upstream support):
http://www.rncbc.org
License:
Qtractor [1] is free, open-source Linux Audio [5] software,
distributed under the terms of the GNU General Public License (GPL [6])
version 2 or later.
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] Linux Audio consortium of libre software for audio-related work
http://linuxaudio.org
[6] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html
See also:
http://www.rncbc.org/drupal/node/1022
Enjoy && Keep the fun, always.
--
rncbc aka. Rui Nuno Capela
Hello!
Some LV2 plugins seem to now the MIDI channel # of the track on which
they are inserted, and some don't.
If I had to guess I'd say that nobody knows, only some plugins can
receive data from several MIDI channels, and some only work with one, so
they never mistake ; Am I right?
Last year I made a GUI around so-404 to learn about LV2 (and C, C++, DSP
code, etc. :)) ; And it has the same problem, just sightly different:
Worse: It starts numbering at 0, so if it's inserted on a track w/ MIDI
#4, you have to select 3
Better: It remembers said channel # on session reload (ZynAddSubFx
doesn't. Yoshimi does)
Can somebody point me towards the light? I'd like my plugin to only
listen to one channel: The one of the host track it's inserted into.
yPhil
--
Philippe "xaccrocheur" Yassin
http://manyrecords.comhttp://bitbucket.org/xaccrocheur / https://github.com/xaccrocheur
Greetings, everyone. Since I am using 85% of JACK DSP in my primary
production box, while using 14% of the CPU and 1/8 of the RAM according
to htop, it appears that I need to develop a way to move forward :-) It
is very clear from the excellent Patrick Shirkey's input that one can
use netjack to chain any combination of motherboards each running JACK;
I would like to use the power of my box to do the same internally.
I have taken a number of hours over the last few days in testing. Thus
far, my impression is that netjack1, netjack2, and jacktrip are
explicitly not set up for this. Using jack2, netjack1 and jacktrip
worked fine for one client/slave, but a second one froze both, and
netjack2 did not work at all, I found a web reference stating that
multijack explicitly does not do localhost unless explicitly set to do
so at the TCP/IP stack programming level. Using jack1, netjack1 did not
connect at all, so I decided to halt for now and ask Those Who Know :-)
So far, the only clearly workable option, has been to try the Docker
lightweight virtualizer, and run each JACK server and related
application chain in its own container. Anyone have better ideas?
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
On Mon, March 7, 2016 7:49 pm, Adrian Knoth wrote:
> On Sun, Mar 06, 2016 at 07:12:25PM -0600, Jonathan E. Brickman wrote:
>
>> Greetings, everyone. Since I am using 85% of JACK DSP in my primary
production box, while using 14% of the CPU and 1/8 of the RAM
>> according to htop, it appears that I need to develop a way to move
forward :-) It is very clear from the excellent Patrick Shirkey's
input that one can use netjack to chain any combination of
>> motherboards each running JACK; I would like to use the power of my box
to do the same internally.
>
> I so don't get what you're trying to achieve. Use multiple soundcards?
Use multiple CPUs? Parallelize the client graph?
>
>
IIUC, it seems that Jonathan has encountered an issue with JACK DSP not
being consistent with cpu load so he is trying to find a way to use
multiple instances of JACK (> 2) on the same machine.
--
Patrick Shirkey
Boost Hardware Ltd
--
Patrick Shirkey
Boost Hardware Ltd
>
> Control of memory ordering and atomics are officially part of the C
>
and C++ languages since 2011. GCC already supported this when the ISO
> standards was finalized. Microsoft and Clang started supporting it in
> 2012. So, it's been pretty much portable since 2012. This is 2016.
> IMHO, it's time to make use of it. :)
Well, atomics are not an official part of the C standard, only the C++
standard. For the jack ringbuffer, Paul could wrap std::atomic into
a C interface in order to follow a langauge standard, but for all practical
purposes, the __atomic_ functions are probably fine to use directly.
On Tue, Mar 1, 2016 at 4:54 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
> On Tue, Mar 1, 2016 at 10:12 AM, Sebastian Gesemann <s.gesemann(a)gmail.com>
> wrote:
>>
>> Thank you all for the responses!
>>
>> On Mon, Feb 29, 2016 at 9:05 PM, Harry van Haaren <harryhaaren(a)gmail.com>
>> wrote:
>> > On Mon, Feb 29, 2016 at 7:52 PM, Spencer Jackson <ssjackson71(a)gmail.com>
>> > wrote:
>> >> > The generic solution for cases like this is a lock-free ringbuffer.
>> >> I've also used the jack ringbuffer for this and it was easy enough.
>> >
>> > Simple tutorial on using JACK ringbuffer and C++ event class here:
>> > https://github.com/harryhaaren/realtimeAudioThreading
>>
>> I've looked into JACK's ringbuffer implementation. It doesn't look too
>> complicated. Thank you all for suggesting it! But I'm a little bit
>> concerned about ISO standard compliance. According to the
>> multi-threading-aware update to the C11 and C++11 memory models, the
>> access to the ringbuffer's data (*buf) is technically a data race and
>> therefore invokes undefined behaviour. Only read_ptr/write_ptr are
>> somewhat protected (volatile). From what I understand, given the
>> C11/C++11 memory model, one is supposed to use "atomics" for all
>> read/write accesses in such situations (including *buf). But so far, I
>> havn't gathered much experience in this kind of lock-free programming.
>
> Sadly, you still don't understand how a lock-free ringbuffer works.
Oh, don't be sad. I'm sure you're underestimating my understanding of the topic.
> The key insight to have is this:
>
> * the calculation of what can be read and what can be written may, in
> fact
> be incorrect due to threading
>
> BUT
>
> they are ALWAYS wrong in the "safe" direction. if the calculation is
> wrong
> it will ALWAYS underestimate data-to-be-read and space-to-be-written.
I understand that.
> that is: you will never attempt to read data that should not be read, and
> you will never attempt to write to space that should not be written. This is
> true of ALL lock-free ringbuffer designs, not just JACK's. The property
> arises from the requirement that they are single-reader/single-writer. If
> you violate this (e.g. attempt to move the read-ptr from the write thread or
> vice versa), then all bets are off unless you use some higher level mutual
> exclusion logic (which has no place in the ringbuffer itself. The design
> works because in audio contexts, when you use a ringbuffer, you are more or
> less guaranteed to be using a design where you keep reading and keep writing
> to the ringbuffer over and over. The design cannot work for single-shot
> communication where you must always collect ALL possible data in a
> thread-synchronous fashion. This is not the case for audio work.
I understand that. So far, nothing you said was new to me.
> Now, that said, there are some under-the-hood issues with the actual JACK
> ringbuffer code, but they have absolutely nothing to do with the high level
> semantics, and that is what you're relying on. Those issues concern the use
> of memory barriers, and are thus related to code-reordering not to
> atomicity.
It depends on what meanings you attach to the words "atomics" and
"atomicity". I was trying to use the term "atomic" in a way consistent
with the C11/C++11 memory model. In this context, atomicity is not
only about having logically multiple operations done as a single one
(fetch-and-add, compare-and-swap, etc) but it also involves memory
ordering hints (defaulting to sequential constistency but weaker
models are possible). So, it seems to me that you were not familiar
with this. I said I have little experience with lock-free programming
but that does not mean I'm completely unaware of the theoretical
aspects.
> Although a clean fix/patch for this would still be a good thing,
> the ringbuffer's are used widely and they function as intended in almost all
> situations.
Sure. I'm not surprized that it works in practice. If the compiler
emits a memory barrier for the volatile memory access, it's all you
need. But technically, it's still undefined behaviour.
> You need not concern yourself with this issue if you are just
> starting out.
Well, for me, that's part of the fun -- figuring out how it's supposed
to be written without invoking U.B.
sg
On Fri, Mar 4, 2016 at 1:22 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com>
wrote:
> You are right. There was even a discussion about how broken it was
> in 2008, and it was fixed, at least in practice.
>
> http://lists.linuxaudio.org/pipermail/linux-audio-user/2008-October/056000.…
>
> Theoretically (and not unlikely also in practice), it seems to be still
> broken.
> This can also confirmed by compiling with -fsanitize=thread:
>
>
I made a quick fix: http://folk.uio.no/ksvalast/ringbuffer.diff
It can probably be optimized by relaxing some of the barrier
strenghtnessness though,
but it probably makes no practical difference in execution time.
Perhaps apply this to jack, at least to avoid uncertainty about whether it
will really
always work?
On Fri, Mar 4, 2016 at 1:00 PM, <
linux-audio-dev-request(a)lists.linuxaudio.org> wrote:
> Send Linux-audio-dev mailing list submissions to
> linux-audio-dev(a)lists.linuxaudio.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
> or, via email, send a message with subject or body 'help' to
> linux-audio-dev-request(a)lists.linuxaudio.org
>
> You can reach the person managing the list at
> linux-audio-dev-owner(a)lists.linuxaudio.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-audio-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Code reordering (Sebastian Gesemann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 4 Mar 2016 10:16:02 +0100
> From: Sebastian Gesemann <s.gesemann(a)gmail.com>
> To: Jonathan Brickman <jeb(a)ponderworthy.com>
> Cc: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
> Subject: Re: [LAD] Code reordering
> Message-ID:
> <
> CAGdQazeKzU1ZOyHrnZLoQnXgm2ca4yZ36+-+xT1MupZMfjTpPg(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Mar 2, 2016 at 5:55 PM, Jonathan Brickman <jeb(a)ponderworthy.com>
> wrote:
> > On 3/1/2016 11:40 AM, Paul Davis wrote:
> >
> > > the JACK implementation relies on two things to work:
> > >
> > > * pointer and integer operations are (weakly) atomic on all
> platforms
> > > that JACK runs on
> > > * code reordering will either not happen or will be prevented by the
> > > compiler
> >
> > Does #2 mean that -O3 should always be avoided when compiling JACK
> clients?
>
> As I said, I consider JACK's ringbuffer implementation to be broken.
> According to the C11/C++11 memory model there is nothing in the code
> that prevents reordering the update to write_ptr and the update to
> *buf in jack_ringbuffer_write. The use of volatile only makes sure
> that read/write accesses to the volatile variables are not reordered
> or "optimized out" by caching. Specificaly, a volatile write is not a
> release barrier. It does not constrain reordering with respect to
> other memory locations (*buf). This makes the access to the buffer's
> content unordered and invokes undefined behaviour.
>
> Having said that, if you can be sure that the compiler does not
> reorder this (by checking the assembly code, for example) then you
> will be fine on an x86/x64 platform because this platform makes an
> extra guarantee: writes in one thread are never seen out of order from
> another thread's perspective.
>
>
You are right. There was even a discussion about how broken it was
in 2008, and it was fixed, at least in practice.
http://lists.linuxaudio.org/pipermail/linux-audio-user/2008-October/056000.…
Theoretically (and not unlikely also in practice), it seems to be still
broken.
This can also confirmed by compiling with -fsanitize=thread:
WARNING: ThreadSanitizer: data race (pid=24978)
Write of size 8 at 0x7d0c0000efd8 by thread T2:
#0 jack_ringbuffer_write jack/ringbuffer.c:247
(test-int-array-jack+0x000000401a30)
#1 writer_start /home/ksvalast/rbtest/test-int-array.c:85
(test-int-array-jack+0x000000400f4d)
#2 <null> <null> (libtsan.so.0+0x0000000235b9)
Previous read of size 8 at 0x7d0c0000efd8 by thread T1:
#0 jack_ringbuffer_read_space jack/ringbuffer.c:108
(test-int-array-jack+0x000000401346)
#1 reader_start /home/ksvalast/rbtest/test-int-array.c:48
(test-int-array-jack+0x000000400df2)
#2 <null> <null> (libtsan.so.0+0x0000000235b9)
Location is heap block of size 48 at 0x7d0c0000efd0 allocated by main
thread:
#0 malloc <null> (libtsan.so.0+0x000000025993)
#1 jack_ringbuffer_create jack/ringbuffer.c:41
(test-int-array-jack+0x0000004010ab)
#2 main /home/ksvalast/rbtest/test-int-array.c:102
(test-int-array-jack+0x00000040100c)
Thread T2 (tid=24981, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:105
(test-int-array-jack+0x000000401056)
Thread T1 (tid=24980, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:104
(test-int-array-jack+0x00000040103b)
SUMMARY: ThreadSanitizer: data race jack/ringbuffer.c:247
jack_ringbuffer_write
==================
==================
WARNING: ThreadSanitizer: data race (pid=24978)
Read of size 8 at 0x7d500000fe00 by thread T1:
#0 memcpy <null> (libtsan.so.0+0x00000002666a)
#1 jack_ringbuffer_read jack/ringbuffer.c:166
(test-int-array-jack+0x0000004015fc)
#2 reader_start /home/ksvalast/rbtest/test-int-array.c:50
(test-int-array-jack+0x000000400e22)
#3 <null> <null> (libtsan.so.0+0x0000000235b9)
Previous write of size 8 at 0x7d500000fe00 by thread T2:
#0 memcpy <null> (libtsan.so.0+0x00000002666a)
#1 jack_ringbuffer_write jack/ringbuffer.c:246
(test-int-array-jack+0x0000004019e5)
#2 writer_start /home/ksvalast/rbtest/test-int-array.c:85
(test-int-array-jack+0x000000400f4d)
#3 <null> <null> (libtsan.so.0+0x0000000235b9)
Location is heap block of size 512 at 0x7d500000fe00 allocated by main
thread:
#0 malloc <null> (libtsan.so.0+0x000000025993)
#1 jack_ringbuffer_create jack/ringbuffer.c:52
(test-int-array-jack+0x0000004011c8)
#2 main /home/ksvalast/rbtest/test-int-array.c:102
(test-int-array-jack+0x00000040100c)
Thread T1 (tid=24980, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:104
(test-int-array-jack+0x00000040103b)
Thread T2 (tid=24981, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:105
(test-int-array-jack+0x000000401056)
SUMMARY: ThreadSanitizer: data race ??:0 __interceptor_memcpy
==================
==================
WARNING: ThreadSanitizer: data race (pid=24978)
Write of size 8 at 0x7d0c0000efe0 by thread T1:
#0 jack_ringbuffer_read jack/ringbuffer.c:167
(test-int-array-jack+0x000000401647)
#1 reader_start /home/ksvalast/rbtest/test-int-array.c:50
(test-int-array-jack+0x000000400e22)
#2 <null> <null> (libtsan.so.0+0x0000000235b9)
Previous read of size 8 at 0x7d0c0000efe0 by thread T2:
#0 jack_ringbuffer_write_space jack/ringbuffer.c:128
(test-int-array-jack+0x00000040141a)
#1 writer_start /home/ksvalast/rbtest/test-int-array.c:83
(test-int-array-jack+0x000000400f1d)
#2 <null> <null> (libtsan.so.0+0x0000000235b9)
Location is heap block of size 48 at 0x7d0c0000efd0 allocated by main
thread:
#0 malloc <null> (libtsan.so.0+0x000000025993)
#1 jack_ringbuffer_create jack/ringbuffer.c:41
(test-int-array-jack+0x0000004010ab)
#2 main /home/ksvalast/rbtest/test-int-array.c:102
(test-int-array-jack+0x00000040100c)
Thread T1 (tid=24980, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:104
(test-int-array-jack+0x00000040103b)
Thread T2 (tid=24981, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x000000027a67)
#1 main /home/ksvalast/rbtest/test-int-array.c:105
(test-int-array-jack+0x000000401056)
SUMMARY: ThreadSanitizer: data race jack/ringbuffer.c:167
jack_ringbuffer_read
==================
