hey linux audio users,
about a year ago i purchased the korg nanokontrol one when they were
dumping them to make room for the nanokontrol II. the last month i'm
finally getting to using it for some csound live processing. but im
beginning to find shortcomings. for one i could use more knobs. also
14bits of resolution would be nice. finally it would be nice if when i
reassign the knobs it would be nice to be able start from the values
they are operating on.
so im looking into the bcr-2000-b by behringer. any linux users had any
experience with this device? any other device suggestions for a budget
minded music coder?
k.
One of the other posts got me thinking a bit, re: all things linux audio.
There are some folks here that kicked over the very first stones. The practicalities and useful application of current day (perhaps taken somewhat for granted) apps (Jack, Ardour , LADSPA... Muse and Rosegarden ... PD, timidity... Et al, were there in some form when I started in 2000, digging in the fields of realtime kernels and lower latencies (kernels 2.4 - 2.6 I think).. Trying to put old laptops and boxes that couldn't run XP to useful tasks...etc.
I don't necessarily have a point to make other than to perhaps see some of where we've been, to further appreciate where Linux Audio is today! Um, we thought man would be on Mars and further when I was a boy. :) we may could have been! Money required to sustain such development is relevant! Developers o any kind can hardly afford no pay... They too have bills to pay, educations, sustenance and roof over thine heads!
Many have come and gone! Some figured how to walk the crevasse of 'free' vs respective remuneration and their development efforts are rewarded with supplemental funds. I don't think any serious linux audio folk have gotten rich from Linux Audio have they?
I would simply like to acknowledge the general core of devs. Without you, we'd all having nothing linux audio to bitch about!! :) I don't care to mention names. They know who they are. I met a few along the way. At San Francisco City Hall of all places!! 1 of which I still see here, 1 I do not.
I personally rely heavily upon Linux and Linux audio these days. It's cost me extreme little in $$ stacked next to proprietary OS. It's powered several semi pro studio platforms, been used at various gigs over the years to record, perform, etc.
A toast! :) to those who persist!
Cheers!
~ Russell
I just cloned the ntk and fable git repos (well, within the last day or
two), installed all the other dependencies, and build fabla. When I run it
with jalv.gtk, a window appears but the GUI is not rendered. There's
nothing unusual in the output in the shell I ran it from. Starting
jalv.gtk with the -d option results in a segfault.
This is on fedora 19.
jalv-1.4.0-2.fc19.x86_64
cairo-1.12.14-2.fc19.x86_64
cairomm-1.10.0-6.fc19.x86_64
libsndfile-1.0.25-7.fc19.x86_64
lv2-1.6.0-2.fc19.x86_64
Has anyone seen this issue before?
Hello,
I'm currently working on a feature for Hydrogen to have multi banks
per instrument.
In a nutshell, if you have drum samples with direct and overhead
recordings, you can put those together under the instruments - one
instrument Snare for example with the band direct and the bank
overhead).
In the Hydrogen mixer, you can chose how much direct or overhead is
needed, changing completely the tone of the drums.
You can chose how many banks you have per instrument, and the gain of
each bank in a given instrument.
A very (very very.......veryveryvery) early version is available here:
https://github.com/blablack/hydrogen
Very early version as the main feature works, but for example I highly
doubt saving/loading songs would work just yet and the mixer GUI goes
a bit crazy when banks are added/removed, I'm in the process of a
massive testing/bug hunt...
I would be very interested to get some early feedback, both on the
feature and (for the most courageous) on the code itself.
Thanks in advance ladies and gentlemen!
Aurélien
To David Christensen who is looking for minimal audio distros:
AVLinux comes in a (somewhat) striped down version you can read about here:
http://www.remastersys.com/forums/index.php?topic=3409.0
In addition AVLinux is built using the Remastersys ISO tools which allow
you to make
a bootable ISO from your system. Hence, you can start with a standard
AVLinux and remove
anything you do not want (or install other stuff) and then make your own
bootable ISO.
Edward Diehl
On 09/04/2014 09:33 PM, Ralf Mardorf wrote:
> -------- Forwarded Message --------From: Ralf Mardorf
> <ralf.mardorf(a)rocketmail.com>
> To: qtractor-devel(a)lists.sourceforge.net
> Subject: Re: [Qtractor-devel] ; ) Was - Re: [LAU] Session management
> with NSM
> Date: Thu, 04 Sep 2014 22:31:15 +0200
> Mailer: Evolution 3.12.5
>
> On Thu, 2014-09-04 at 21:27 +0100, Rui Nuno Capela wrote:
>> On 09/04/2014 07:49 PM, Ralf Mardorf wrote:
>>> Rui :)
>>>
>>> please consider to automatically add to
>>>
>>> File > Properties ... > Description
>>>
>>> the jackd "in" and "out" reported latency ;). Since the MIDI resolution
>>> steps don't provide ms, frame information, a written note could help to
>>> fix sync problems, without using a calculator.
>>>
>>> (I don't need it, perhaps you could add an option to the preferences, to
>>> uncheck this feature ;)
>>>
>>
>> jack_lsp -l does report latency of every port
>>
>> byee
>
> It doesn't report the latency a session was recoded 2 years ago.
>
and why would that be interesting?
qtractor does its "recording/input latency compensation" of audio cľips
*at the time* the audio material is captured, so that material gets
aligned with the audio/MIDI content already in session and possibly
being played back at the time of the recording. never again it gets
adjusted no matter what jackd parameters change later, be that for worse
or better. that's it.
please understand that this is the only kind of latency compensation
qtractor does and nothing else. nb. qtractor does NOT compensate for
in-line output or plugin chain latency. never did and quite frankly it
won't do so soon, i'm afraid.
i really don't see how having distinct jackd i/o latency settings
(buffer-size, periods, sample-rate) may lead to audio going out of sync
to MIDI--if it does get out-of-sync anyway, it is probably because
something else but latency compensation related, not to tell that
session-management has nothing to do with either.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
ps. if audio and MIDI get out of sync, timer type and/or resolution
might be the top suspect.
Hi,
after many years of wondering now and then I am curious what
qjackctl's display of "DSP load" is supposed to mean?
It must be some kind of CPU load, as there is no dedicated DSP in my
computer, so is it the cpu load of the jackd process?
Furthermore I wonder why the realtime "RT" indicator in qjackctl's
window is blinking about every 2 seconds. I do have -rt enabled.
Thank you for helping me to find answers to these things that are
puzzling me since quite some time.
best, P
On Fri, Aug 29, 2014 at 8:32 PM, Philipp Überbacher <murks(a)tuxfamily.org> wrote:
> Thanks a lot for your reply Harry.
Cheers, be careful to not remove the list from replies: its good to
keep everything in the archives for future reference :)
>> That's the correct way to handle this, as far as I know. Its useful to
>> have different directories on one system: it allows subdiving your
>> available sessions into groups like "albums" or
>> "projects-with-certain-people". Although I agree it feels a little
>> clunky, its quite powerful and useful.
>
> There could also be a subdivision in the NSM GUI. Well, the current way
> is certainly the simpler implementation, not sure it's simpler for the
> users :)
Sure, and my original suggestion was a "stepping-stone" type idea,
with hopes to improve the workflow furthur, once this has become the
"biggest" issue NSM has :D
>> > 2. Adding programs to sessions through the GUI ("Add Client to
>> > Session") is the only way? Is there no way to attach running clients
>> > or at least have some comfort like tab completion to add clients?
>> NSM does not support this "attach" workflow, but tab completion or a
>> list of available (fully supported) NSM clients would be a good
>> improvement on workflow. This should be discussed as to how best
>> implement it: i'm not sure.
>
> Right, a list of supported Clients would also be nice, however, I see
> two problems:
> 1. The list would need to be updated somehow, and even then it would be
> a bit problematic because different distributions ship different
> versions of the software. NSM might already list a program as supported
> while the installed version of the program does not yet support NSM.
> 2. The other programs, audio or just related, should ideally also be
> listed, and that task is impossible.
Actually this might be possible to solve with a "packaging" trick as
such: have programs install a file into a specific location (that is
currently *not* used by any program) to denote its NSM support. I'll
suggest installing a file in /usr/share/nsm/ , and if there's a file
there, then the filename without extension represents that a program
is capable of NSM. This would require *all* NSM clients to explicitly
add an NSM file.
Perhaps other developers more involved in packaging /
"feature-announcing" will have a better idea here, I'm all ears, my
suggestion above is just that: a suggestion.
>> > 3. Jack and NSM. How do you handle that? It is possible to start
>> > jack through NSM proxy and I guess it is OK to do that as long as
>> > jack reliably starts before jackpatch (something I'm not sure of).
>> > First I had just jackpatch in there and it started jack for me with
>> > a whole lot of options that are unfamiliar to me and probably not
>> > needed.
>>
>> I imagine that NSM will launch said JACK apps, and if one is set to
>> "start JACK" on jack_client_open() in its code, then it will start
>> JACK with the settings in ~/.jackdrc Perhaps the inclusion of a
>> "Start JACK" type client with particular settings can be implemented
>> in order to handle this? I'm open for suggestions too.
>
> That seems to be what happens, and its a race. In my experience
> jackpatch wins the race against jackd, so I have to start jack before
> the session.
> A start_jack client could be useful, but from what I have seen all we
> really need is the possibility to start a client before the others.
> The simple way would be a timeout, but you'd still have the
> race. Ideally there would be some way to tell NSM that jack has
> started and is ready. I have doubts that this is possible with plain
> jack1 and NSM proxy, maybe a special start_jack client could help here.
NSM doesn't *explicitly* require JACK to be running actually: its
probably its most common use right now, but setting an explicit
dependency on JACK should be avoided. Perhaps a flag could be
introduce on a per-client basis, that represents
"start-before-others". This way, a "jackd" or "start-jack" client can
be loaded before the rest. Or even two or more "before-others" clients
could set up whatever needs setting up, before "normal-time" NSM
clients are loaded.
Again, welcome input from users / devs.
>> > 4. CLI clients. Are they generally not supported? I added the lv2
>> > host that was recommended to me (jalv) and had to do that through
>> > the NSM proxy, so the settings won't be saved even though the
>> > plugin (fabla in this case) can save its settings. This sort of
>> > defeats session management. With all the CLI tools we have it would
>> > be a pitty if that was generally not supported. On a sidenote, can
>> > someone recommend a plugin host that is supported?
>>
>> CLI clients are supported just like clients with a GUI, there is no
>> difference to NSM. The issue you're encountering here is that JALV
>> currently doesn't support NSM, which is something that I agree needs
>> fixing. I'll put JALV NSM support on the TODO, its something I've
>> lacked myself too.
>
> Ok, great. Does a CLI NSM client exist that I can try?
None that I know of right now: Indeed JALV needs NSM, and jalv (the
command line version) will then be such a client.
> I also noticed that JALV keeps hanging around
> after I close the session it is part of, is that expected behavior?
This can be fixed by sending the "SIGTERM" in the lower part of the
"nsm-proxy" configuration dialog (where you fill in "jalv.gtk", and
the arguments to load a certain plugin).
>> > Well, that's it for now. Last time I heard about NSM I got the
>> > impression that it takes care of session management once and for
>> > all, but the first half our gave me a different impression.
>> OpenAV stands behind NSM: I'm willing to do my best to cooperate with
>> project developers to implement NSM in various programs, and improve
>> the workflow of session management.
>>
>> If there's any furthur questions, please ask, in the mean time, I'll
>> try code up some NSM :) -Harry
>
> Thanks a lot for your help Harry, we have used crutches for session
> management long enough.
Agreed, lets try fix this together with the communit in the next
weeks, and never look back ;)
Cheers, -Harry
