Hi all
GSequencer version 0.7.10 got released as stable. Plugin support has
been extended from LADSPA to DSSI and LV2. Although it's not yet
perfect some of those plugins can be used for now. It needs further
investigation why certain plugins don't work.
For now values from GUI get converted to appropriate scale.
Rudimentary MIDI input exists as well but it wasn't tested, yet. For
sequencers and instruments there exists a connection editor supporting
JACK and ALSA backend.
Theoritcally you should be able to output to JACK using GSequencer.
But JACK support needs some fixes because you can't link jackserver
and jack both in the same application.
http://gsequencer.org
bests,
Joël
We're proud to announce the immediate availability of DrumGizmo version
0.9.9!
Highlighted changes / fixes:
- Switch to LGPLv3
- Linux VST
- Embedded UI
- Prepped for diskstreaming (but not yet implemented in UI)
- Loads of bug fixes
Read the ChangeLog for the full list of changes
Download it from http://www.drumgizmo.org
Visit us at the official irc channel at the Freenode network. Channel
name #DrumGizmo. We would love to hear from you!
// The DrumGizmo team
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
