On Friday 06 January 2012, you wrote:
> btw: is there a way to list available clients/ports from the api.
> I know that aconnect -i / -o does this, but is there a c/c++ function?
>
> Dave
The functions are: snd_seq_query_next_client() and snd_seq_query_next_port();
you need to loop calling these functions while they return a correct answer.
For instance, this is the relevant code in "aconnect.c" :
static void do_search_port(snd_seq_t *seq, int perm, action_func_t do_action)
{
snd_seq_client_info_t *cinfo;
snd_seq_port_info_t *pinfo;
int count;
snd_seq_client_info_alloca(&cinfo);
snd_seq_port_info_alloca(&pinfo);
snd_seq_client_info_set_client(cinfo, -1);
while (snd_seq_query_next_client(seq, cinfo) >= 0) {
/* reset query info */
snd_seq_port_info_set_client(pinfo,
snd_seq_client_info_get_client(cinfo));
snd_seq_port_info_set_port(pinfo, -1);
count = 0;
while (snd_seq_query_next_port(seq, pinfo) >= 0) {
if (check_permission(pinfo, perm)) {
do_action(seq, cinfo, pinfo, count);
count++;
}
}
}
}
See:
http://git.alsa-project.org/?p=alsa-utils.git;a=blob;f=seq/aconnect/aconnec…
I guess you already know the reference documentation site:
http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html
Just for comparison, a similar enumeration using Drumstick looks like this:
QListIterator<PortInfo> it(m_Client->getAvailableOutputs());
while(it.hasNext()) {
PortInfo p = it.next();
cout << p.getClientName() << ":" << p.getPort();
}
See Drumstick's example "drumgrid":
http://drumstick.sourceforge.net/docs/drumgrid.cpp-example.html
Regards,
Pedro
Hello everyone,
During this jolly holidays, I worked a bit on the AMS LV2 plugins.
The version 0.0.6 can be downloaded here:
http://sourceforge.net/projects/avwlv2/files/avw.lv2.0.0.6.tar.gz/download
This new version comes with:
* Basic GUI for Analog Driver, Envelop and Advanced Envelop
* Ported:
- CV Source
- Delay
- Dynamic Waves (4 Osc)
The basic GUIs are based on the ones from AMS itself.
In addition, the SVN is now fixed:
svn checkout svn://svn.code.sf.net/p/avwlv2/code/trunk avwlv2-code
Finally, plans for the future are to port more of the AMS plugins (I'm
sorry guys, but I'm only gonna port the ones I actually use and might
ignore some others).
I was thinking as well to:
- create a percussive envelop and 'Note Filter' (a plugin that let the
Velocity/Gate/Trigger of the Ingen Note Internal go through only when
a certain Frequency is hit). I have patches that simulate the TR 808
Kick/Snare/Etc, and I need these to be able to create a Drum Machine
in Ingen.
- create a beat slicer/repeater plugin (probably will base the code on
Tranches).
- a LFO synchcronized with Jack (I have always missed that one AMS!).
So here you go!
Have a happy new year 2012 guys!
Aurélien
The discussion started, with the question about large files.
Keep it simple - store either files or links in the session folder ?
Why not ?
Some more opinions please.
--
E.R.
Hello list,
tl;dr: Is there a cheap midi hardware that just gets midi information in and routes it out, except on a different, single, channel which I can change easily up and down directly on the hardware?
Long version:
Recently my master keyboard broke. It was just a cheap, used m-audio keystation 49e. I did not buy a new master-keyboard because I have a Roland HP207e digital piano here which is vastly superior when it comes to actual playing. Sadly not to control midi data.
I have a Behringer BCF2000 here which I connected to my keyboard now, so I should be able to do something with it, but there is one thing missing: Channel Changes.
Anybody who worked with Linuxsampler knows that channel switching is very important to switch instruments, while program changes are neglectable.
So maybe there is a way to use my piano, which always sends on the first channel (except I dive into inaccessible menus) if
a) I find a way to shortcut the "change channel" command, but I don't know how. It has midi in and a usb connector, but that is not used to control it, just to send and receive midi data. Incoming data gets interpreted like a sampler does.
b) There is a way to use my BCF2000. I am very inexperienced with that thing.
c) There is a cheap standalone hardware, just a "little box", I can plugin between my linux box and the piano, which re-routes the midi data, like I mentioned in the short version above.
d) I build something myself, a small linux plug computer where I somehow attach two buttons (ch up and dow) and use the usb connections. At least the cables are cheaper :) But this is the most unrealistic method, although it might be the most interesting one.
Maybe you know something?
Nils
P.S. I know I can do the channel routing directly on my linux computer, after receiving the data and before sending it to a sampler. But that is inconvenient.
Hi,
I wonder what the LAD community thinks about Non Session Manager
http://non.tuxfamily.org/nsm/API.htmlhttp://non.tuxfamily.org/nsmhttp://www.youtube.com/watch?v=ui-gC_ZMeGMhttp://youtu.be/xzspJXbEoc0
From a user POV I must say that it works very smooth at first sight.
It's easy to use and one of the strong points seems to be the
flexibility, e.g. the ability to copy and change existing sessions, run
multiple sessions (also via network). But I cannot comment on the
technical goods and bads of the API and how easy it will be to implement
this in a Jackaudio application. It seems to use OSC messages and
depends only on liblo.
Thanks in advance,
\r
Hi Everyone
Im would like to experiment using microphone arrays ( 24 channels ) and I
am just wondering if it is possible for me to use 3 units of Behringer
ADA8000 connected via ADAT to HDSP 9652. My tools run only with ALSA
supported devices and I checked through ALSA website, the HDSP 9652 seemed
to be OK. Im just wondering if the set-up I mentioned is possible ? Will
there be any issue at all if i use the ADA8000 as far as ALSA is concerned
? Thank you very much, I really would appreciate any suggestions or
comments. Thank you
Phil
On Thu, Mar 22, 2012 at 09:03:12AM +0100, Emanuel Rumpf wrote:
> Am 21. März 2012 18:28 schrieb Joel Roth <joelz(a)pobox.com>:
> >
> > https://github.com/navicore/Jacks
> >
>
> hm ...
> The code uses a mutex_lock in the process callback:
>
> _lock(_this_);
> _this_->nframes = nframes;
> _unlock(_this_);
>
>
> From the doc of pthread_mutex_lock: "If the mutex is already locked,
> the calling thread blocks until the mutex becomes available."
>
> A try-lock (pthread_mutex_trylock) may be less likely to disturb jacks
> process flow.
>
> --
> E.R.
Hi folks. I'm the author, new to the list, new to audio, been on
vacation but back now and hoping to learn and contribute. Programming /
playing with jack has been fun!
Emanuel, thx for the suggestion. The job of that mutex is to block the
callback until the user code has run, _trylock wouldn't do that.
It is the same approach jack uses when you call jack_session_reply, an
event completion token pattern that runs this code from jack engine.c
<code>
static void
do_request (jack_engine_t *engine, jack_request_t *req, int *reply_fd)
{
/* The request_lock serializes internal requests (from any
* thread in the server) with external requests (always from "the"
* server thread).
*/
pthread_mutex_lock (&engine->request_lock);
</code>
I intend to change to _timed_lock for safety but the mutex is there to
serialize execution between the callback and the perl/python/ruby/lua
user code. Open to different designs but this one lets me expose the
Jack API to multiple languages with one swig.i file and lets the user
program in a synchronous style.
The overhead of the context switching and locks is unfortunate. Works
fine for me reimplementing the example-clients with 48000 sample rate
but I'm a n00b and don't know what real processing looks like.
Can anyone point me to a way to stress test? I'd like to know at what
point all the overhead of my approach plus the costs of the host lang
VMs breaks things.
Btw, I'm sure the main value of a pkg like this is the session api and
not the processing. If you don't open any ports it won't register the
process_cb callback with Jack and you won't have the processing costs.
Regarding the build/install, I intend to make the main build system
generate platform distribution-friendly installable dist files rather
than the ./configure stuff it uses now. CPAN-friendly, rubyrock,
luarock, etc...
Sorry for the long post
-Ed
Hi phil,
i used different distros... at the moment im using linux mint 12 with rt
patch, ubuntu studio 9.04 to 10.04 with lowlatency kernel. on any system
the 9652 was running fine.
if you just want to record stuff you dont need rt.
only if you want to do processing of any kind, rt is needed.
the 9632 has no expansion board, therefore it only has 16 in and 16out.
the 9652 is the same card but with the expansion board, capable of 24
in/out.
bye
Ck
On 28.03.2012 14:59, Phil T wrote:
>
> Hi Christoph,
>
>
> Thank you ! I am really new to hardware and stuff. I am just
> wondering what linux distro are you using ? Do you think ubuntu may
> suffice ? I have read some threads suggesting to manually compile a
> kernel enabling rt and Im just wondering if you have manually compiled
> a kernel in your case ? Lastly, in the RME homepage, it says that the
> HDSP 9652 can have up to 16 inputs. However if I am not mistaken, it
> also says it has 3 ADAT input so Im just wondering with 3 ADAT input,
> it could be possibly take in 24 inputs all in all. Thank you very much.
>
> Phil
>
>
>
>
>
>
>
> On Wed, Mar 28, 2012 at 6:35 PM, Christoph Kuhr <christoph.kuhr(a)web.de
> <mailto:christoph.kuhr@web.de>> wrote:
>
> Hi,
>
> im running it for a few year... works perfect
>
> bye
> Ck
>
> On 28.03.2012 01:44, Phil T wrote:
>> Hi Everyone
>>
>> Im would like to experiment using microphone arrays ( 24 channels
>> ) and I am just wondering if it is possible for me to use 3 units
>> of Behringer ADA8000 connected via ADAT to HDSP 9652. My tools
>> run only with ALSA supported devices and I checked through ALSA
>> website, the HDSP 9652 seemed to be OK. Im just wondering if the
>> set-up I mentioned is possible ? Will there be any issue at all
>> if i use the ADA8000 as far as ALSA is concerned ? Thank you very
>> much, I really would appreciate any suggestions or comments.
>> Thank you
>>
>>
>> Phil
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev(a)lists.linuxaudio.org <mailto:Linux-audio-dev@lists.linuxaudio.org>
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> <mailto:Linux-audio-dev@lists.linuxaudio.org>
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
Hi all,
Pretty strong consensus is that the LV2 specs being a bunch of packages
is a nuisance. So, I plan to start releasing them all in one package.
People have asked for this, but I'm not positive it's what they want.
The main odd consequence would be packages checked by configure scripts
(via pkg-config) will not correlate with tarballs. For example, a
program may check for lv2-state-2.4 but no tarball with that name will
actually exist. It will be in lv2-everything-2012-03-21 or whatever.
It would be difficult to correlate which version of lv2-everything
contains a recent enough version of what you need, if something is
failing to configure.
I don't think it's feasible or wise to mash everything in to one package
right down to the pkg-config level, but I'm open to arguments otherwise.
Extensions are independently versioned so changes to them don't affect
the version of others. In all the ways that count, extensions are
completely decentralized and separate (anyone can make one and
distribute it, or not, on their own), but maybe that doesn't mean they
need to be packaged that way?
In short, I am ready and willing to reshape the packaging to make life
easy and to ease adoption as much as possible, but nobody has come up
with exactly what that is. All suggestions welcome, including blatant
"this is all ridiculous crap and you should just <painfully simple
approach here>" kind of thoughts...
Cheers,
-dr
