[LAD] Q 7.8 released
Hi all, I've just released Q 7.8 which sports some important bugfixes and some nice new features. The most important addition probably is that Q now has a complete Qt interface. You can find the sources and a ready-made RPM for Linux (which contains almost everything surrounding Q, including the interfaces to Faust, MidiShare, Pd and SuperCollider and the multimedia examples) on the Q download page: http://q-lang.sourceforge.net/download.html For those of you who haven't heard about Q yet: It is a GPLed, modern-style functional programming language with good library support for multimedia and computer music applications. (Somewhat like Haskell, but interpreted and dynamically typed, and with much better system and multimedia libraries.) More information about Q can be found on the Q website at: http://q-lang.sourceforge.net Enjoy. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jmax & jack
Hi Fons, do you have a reason not to use Pd instead of jMax? It works well with Jack and you can easily change the number of Jack ports on the fly. And since I know that you like minimal GUIs you might like Pd better anyway. ;-) Cheers, Albert Fons Adriaensen wrote: > Anyone knows how to create unconnected and sensibly named > jack ports in jmax ? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK & MIDI
Julien Claassen wrote: > And about the two APIs: why not? If you think about it thorroughly I'm sure > one can come up with a protocol, of which MIDI is a subset. Thus some > interaction between to apps (one using MIDI, one using the new thing) could > be > possible. The entire keyboard/synth industry has been trying to do that for a decade now, and only now it's beginning to take shape (MIDI 2.0). There's just so much cruft in MIDI 1.0 that it's hard to extend it without breaking it. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] JACK & MIDI
Fons Adriaensen wrote: > Seriously, there are three things that I profoundly dislike in MIDI. > > 1. The limited precision of almost all values, 7 bits or 14 with a >kludge (but even this kludge is not available in any standard >way for e.g. individual note frequencies). Agreed. The MIDI Tuning Standard (MTS) was invented to fix that, but it doesn't really help with the "12 notes per octave" limitation and, being sysex, isn't really realtime, so it wouldn't be suitable to tune Aeolus on the fly anyway. So I guess the only real option for Aeolus right now would be to support both MIDI (possibly via Jack) for the basic "I'm a 16 part MIDI organ with 12 notes per octave" interface and OSC for dynamic voice allocation and the advanced "I can play any n-tone temperament and even change them on the fly" stuff. (I vaguely recall that this has been dicussed here before, so maybe Aeolus already has an OSC interface?) Just my 0.0002 semitones. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK & MIDI
Paul Davis wrote: > i don't know that it matters, but this is not strictly how it happened. > JACK was developed out of Ardour's initial AudioEngine object. As a > result, when the first version of JACK was available, Ardour could > already use it. how much of an incentive or disincentive this was to > JACK's adoption is probably not relevant. It surely didn't hinder it. ;-) But seriously, this is an important point. You can't just come up with an extended protocol like this without knowing a great deal about the demands of advanced applications in this realm (SuperCollider et al). Most people just talk about MIDI's resolution issues, which are important, but there's other things that would be good to have in a "better than MIDI" protocol: - Dynamic voice allocation, a.k.a. a way to manage a lot of temporary voices. - Flexible and easy controller mapping, to make it easy to interface to different between different hardware and software. - Feature discovery. Something like what controller types does this device/software understand, what are the default values and ranges of controllers, etc. That's from the top of my head, I'm sure there are other points to consider. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK & MIDI
Fernando Lopez-Lezcano wrote: > Is there anything inherently wrong with OSC as a _transport_ protocol? > Anything that makes it unsuitable for that purpose within the framework > of jack? (I know there have been threads about this before) I second that. Why invent yet another protocol when there's already a kind of standard available? But, besides the lack of out-of-the-box semantics, there's another potential issue with OSC, namely that OSC packets can get arbitrarily large. That might be a problem with Jack. I don't know enough about Jack's internals to assess the impacts of this, but I imagine that a realtime-capable gc would be needed to deal with this. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK & MIDI
Paul Davis wrote: > OSC is not a bus-oriented protocol, its 100% point-to-point. That is, > you do not put messages on a bus and all listeners pick it up. Well, actually OSC uses a server/client model (at least the OSC apps I know do). In any case, OSC clients just connect to servers, and that server might well be Jack. OSC servers like SC3 would have to adapted, though, that's true. But first and foremost, OSC is just a way to cram data with attached type information into a buffer, so, as Dave already pointed out, you can just ignore the transport layer and provide your own API instead. Audio applications also need to be Jack'ified to work with Jack after all... What jack could maybe do, in addition to provide a transport mechanism for both OSC and MIDI, is to allow connections between MIDI and OSC and do the translation on the fly (using some set of MIDI-over-OSC messages). That would be cool. Jack'ified apps could then just happily use OSC as their control protocol and never worry about MIDI any more. I don't know whether it's practical to add that functionality to Jack; otherwise there could be a Jack client doing that kind of thing. Also, implementing something like OSC in Jack would vastly expand its scope. Want to process sensor data from your Gizmo ABC(TM) measuring equipment or your brandnew "I Robot" Mark II vacuum cleaner? Sure, why not, just write a Jack client which reads the data and translates it to OSC, now you can pipe it into any Jack application, maybe via another Jack client which does the necessary controller mapping. This might sound like a pipedream now, but with cpu speeds always on the rise and manycores in every PC soon the processing power will be there. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] alsa and OSS (again?)
Dave Phillips wrote: > You can look at Albert's patches to see what he fixed that enabled a > clean compile. Well, besides the lack of 64 bit support, what makes Midishare so hard to compile and install on Linux right now, is mostly related to getting the Midishare kernel module to work on different iterations of the 2.6.x kernel, as the kernel API is still a moving target (which certainly isn't Grame's fault). It would likely be much easier if the kernel module could be replaced by a user space driver, but support for that in the 2.6 kernel is relatively new and noone has looked into that yet. Another issue, also related to the kernel module, is that the necessary init.d logic and kernel devices support (udev et al) varies among different distros, and sometimes even between different minor versions of the same distro. Unfortunately, autoconf doesn't help with that. When this stuff finally settles, it will be much easier to create a Midishare version for Linux which just works out of the box. This problem is not in any way unique to Midishare, just look at the mess with graphics and wireless drivers. You just don't notice it as much as these are usually already included in your distro. Dave, I can't help you right now with getting Midishare to work on 64 bit system, but if you're willing to run it on 32 bit I'll try to help you getting it compiled. Just drop me an email. Best, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] alsa and OSS (again?)
Fernando Lopez-Lezcano wrote: > Or, if from the get go it would have been included in the mainline > kernel source (after submitting it to the proper channels, etc, etc - > difficult but not impossible. Out of mainline kernel drivers have always > been a pain...). True, but (1) as you mentioned, the barrier to entry is high, and (2) even if it is accepted, who is going to maintain it? Researchers are usually busy with other things, and are not delighted by the prospect to go with each and every new kernel release just to update a single driver. ;-) Maybe it's possible to unbundle the MidiShare Linux driver from the main sources. That alone would make it much easier to provide frequent updates or patches for different kernel versions, and would provide a path to get the driver into the kernel at some point. From my experience, the rest of the MidiShare sources should compile on any modern Linux distro without much ado. (Well, the old gtk apps included with Midishare can be a headache since they require the gtk1 compat libs, but this could be made a configure-time option.) > I did wrestle with midishare a while back for Planet CCRMA (for > openmusic, same as Dave) and I'm not looking forward to a rehash of > that :-) It would certainly be nice if PlanetCCRMA included Midishare again. :) I'm currently getting a new laptop on which I can finally run PlanetCCRMA alongside with SUSE again, so I'll probably look into that when I have the time. It shouldn't be too difficult to adapt my patches for FC8. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] alsa and OSS (again?)
Jay Vaughan wrote: > Well I have it working fine on both 2.4 and 2.6 kernels, so I don't know > what the dilemna is here, really .. Judging from what I read on the Midishare list, most Linux users of Midishare indeed have trouble dealing with compilation probs in the kernel module. Not you and me, but you can't expect end users to be able to handle problems due to the ever-changing kernel API. This stuff isn't trivial. You don't have to be a kernel hacker (I'm certainly not), but you really need to understand the Midishare code if you have to sift the kernel headers for a replacement for some kernel routine which just miraculously disappeared, thanks to your friendly kernel dev cleaning up the kernel code. I've done it more than once... > And actually I really like the Midishare design Nobody argues that. I'm also using it for all my MIDI needs. >> Another issue, also related to the kernel module, is that the necessary >> init.d logic and kernel devices support (udev et al) varies among >> different distros, and sometimes even between different minor versions >> of the same distro. > > This is not MidiShare's fault. Of course not. But you still have to deal with it. :) > There are no kernel drivers in MidiShare, only kernel modules. That's what I call the Midishare driver. As I said, the userspace stuff, Midishare library and all that, compiles quite easily on almost any Linux system. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK & MIDI
Jay Vaughan wrote: > I don't think its fair to say that MIDI is encumbered by cruft. It is. Using NRPNs or sysex to send >7bit controller values, microtones and whatnot is possible, but for the former the events are not atomic and for the latter they are not really realtime. MIDI is good for what it does, and it is still useful. I didn't criticize MIDI for what it is, but pointed out why it's so hard to extend beyond what it was originally conceived to be. This makes it worthwhile to think about alternatives like OSC in Jack (yes, as an alternative to MIDI, not as a replacement). I think nobody is going to argue that MIDI support in Jack is useful. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] alsa and OSS (again?)
Fernando Lopez-Lezcano wrote: > Yes, but it is the only way to make midishare "mainline". So that it > will always work with any vanilla distribution kernel (that has, of > course, enabled its build). Agreed. > The other option would be to implement all of midishare in user space. That would be my preferred solution. IIRC, the kernel module was needed (in the days of kernel 2.4 or 2.2 that is) to have a reliable timer interrupt and lowlat IPC. It should be possible to do this entirely in userland now, but there might be other issues I'm not aware of, we'll have to ask Yann about it. As we'll probably meet at LAC we might have some time to discuss it there. > Well, the kernel maintainers of course. And whoever is maintaining it > now (sorry, I don't who that might be). Grame. (I'm just a user myself, I only provide SUSE RPMs and update these according to my own needs.) > They don't need to update the kernel. No, what I meant is that you'd need to follow each dotdot release of the kernel and update the Midishare module accordingly. Not a big deal if you follow all kernel releases anyway, but I don't have the time to do that and neither does the Grame team AFAIK. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] alsa and OSS (again?)
Ivica Ico Bukvic wrote: > If ALSA sequencer is subpar to Midishare I think there's a misunderstanding there. The goals of these projects are different. Midishare doesn't aim to replace ALSA, in fact it works with ALSA sequencer (as well as OSS and a number of other interfaces on different platforms). Midishare is a high-level, cross-platform MIDI API which has been around on various platforms long before ALSA, and even before Linux was a blink in Linus' eye. It's similar in scope to PortMidi, but more mature and offers more features. In fact I think that the ALSA sequencer was inspired by Midishare in some ways, but that doesn't mean that one should be replaced by the other. Some ppl prefer the features and cross-platform compatibility that Midishare offers, others don't want an extra layer between them and their MIDI interface and don't care about cross-platform compatibility, so they rather go with plain ALSA instead. To each his own. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] alsa and OSS (again?)
Fernando Lopez-Lezcano wrote: > It would make a BIG difference to have all of midishare in userland. I > think the latest kernels implement high resolution timers, etc. If Jack > can be made to work in userland, midi should be possible as well. I'd think so, too. > If I understand the kernel development process correctly, once the midishare > kernel module is in the mainline kernel the update process is fairly > automatic. Ok, I see. Yes, that makes it easier. I'd still prefer the userland option, if it's feasible. Let's see what the people at Grame think about this. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Darren Landrum wrote:
> If you wanted to quickly prototype an idea for a DSP routine, how would
> you go about it? It would need to work in real-time, but it wouldn't
> really need to be super-efficient for testing ideas.
As long as the DSP doesn't need any tight feedback loops, Pd [1] or some
such patching environment is probably the easiest way to go.
[1] http://puredata.info/
For more advanced stuff, or if you need to build your own custom DSP
components, use Faust [2]. It's the most advanced DSP programming
language available right now. Also, it's a real DSP language which
allows you to program to the bare metal, instead of just patching
together some ready-made components. I guess that's what you want.
[2] http://faust.grame.fr/
Faust is a purely functional language (signals are streams of samples,
DSPs are functions operating on those, which can easily combined in
various ways using Faust's block diagram operators). It compiles to C++,
output code is very good (comparable to carefully hand-crafted code),
and it interfaces nicely to different environments like Jack, LADSPA,
Pd, Max/MSP, VST, SC3, to name just a few. There's also a script to
generate ready-to-use Pd patches from Faust programs which makes testing
pretty easy. Also, you can compile your Faust programs online on the
Faust website if you don't want to bother installing the Faust compiler
(which is quite easy, though, it should readily compile on any Linux box).
For more information, see Yann Orlarey et al's LAC/ICMC 2006 paper and
my LAC 2007 paper (the latter is specifically about the Faust-Pd
interface). You can find these and a lot more on the Faust website [3].
Julius Smith from CCRMA has a tutorial and various examples [4,5], and
you can find some further Faust examples like guitar effects, various
synthesis algorithms and even a KCS decoder on my Q website [6]. The
Faust distribution also includes a lot of examples. (There's no book on
Faust yet, so right now you'll have to find your way using the examples,
the quick reference guide included in the Faust distribution, and the
various tutorials available.)
[3] http://faust.grame.fr/pubs.php
[4] http://ccrma.stanford.edu/realsimple/faust/
[5] http://ccrma.stanford.edu/realsimple/faust_strings/faust_strings.html
[6] http://q-lang.sourceforge.net/examples.html#Pd
Faust has a learning curve, especially if you never used a functional
programming language before. But it's definitely worth it, and it's
addictive. ;-) Once mastered, you can program fairly complex DSPs in a
few lines, and you don't have to worry about those nasty block wrapover
issues which make programming non-trivial DSPs directly in C a pita. And
since the output code is just plain C++ (the compiled DSP algorithm
itself is actually C, being wrapped up in a C++ class for tidyness), you
can easily integrate it into your own programs once you're done prototyping.
To whet your appetite, here are a few Faust examples. A simple chorus
effect:
chorus(dtime,freq,depth,phase,x)
= x+level*fdelay(1<<16, t, x)
with {
t = SR*dtime/2*(1+depth*tblosc(1<<16, sin, freq, phase));
};
Or how about a generic biquad filter:
filter(b0,b1,b2,a0,a1,a2) = f : (+ ~ g)
with {
f(x)= (b0/a0)*x+(b1/a0)*x'+(b2/a0)*x'';
g(y)= 0-(a1/a0)*y-(a2/a0)*y';
};
Note that ~ is Faust's feedback loop operator; the local f function is
the feedforward, g the feedback part of the filter. x' means signal x
delayed by one sample. Pretty easy. And here's how you use that
definition to define a low shelf filter, straight from Robert
Bristow-Johnson's Audio EQ Cookbook. f0 is the shelf midpoint frequency,
g the desired gain in dB. S is the shelf slope parameter, we always set
that to 1 here:
low_shelf(f0,g) = filter(b0,b1,b2,a0,a1,a2)
with {
S = 1;
A = pow(10,g/40);
w0 = 2*PI*f0/SR;
alpha = sin(w0)/2 * sqrt( (A + 1/A)*(1/S - 1) + 2 );
b0 =A*( (A+1) - (A-1)*cos(w0) + 2*sqrt(A)*alpha );
b1 = 2*A*( (A-1) - (A+1)*cos(w0) );
b2 =A*( (A+1) - (A-1)*cos(w0) - 2*sqrt(A)*alpha );
a0 =(A+1) + (A-1)*cos(w0) + 2*sqrt(A)*alpha;
a1 = -2*( (A-1) + (A+1)*cos(w0) );
a2 =(A+1) + (A-1)*cos(w0) - 2*sqrt(A)*alpha;
};
You can find these examples and a lot more in my Faust guitar effects
collection (see ref. [6] above). Also make sure to take a look at Julius
Smith's examples, he's Da Man. :)
HTH,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
WWW:http://www.musikinformatik.uni-mainz.de/ag
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Darren Landrum wrote: >> [1] http://clam.iua.upf.edu > > That one I *didn't* know about. That's almost like Reaktor! I'll > definitely be giving that one a go. Thanks! Yes, CLAM is nice. If I'm not mistaken, a new version is around the corner. And it interfaces to Faust (see my previous reply), via LADSPA. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Kjetil S. Matheussen wrote: > If you _really_ like functional programming and aren't > afraid to learn a really different syntax, faust might probably > be a very good alternative. I don't think you'll get the kind of tight > interactive development environment with it as the other systems > though. ie. you have to write code, compile up, run test, etc., > while in the other systems, you can just write code and test directly. That's true, I'm the first one to admit that as I already use the Faust/Pd combination in courses, and the students complain about this all the time. ;-) We definitely need to work on that. This might need some cooperation from Pd (right now, Pd doesn't seem to like reloading externals on the fly, at least I haven't figured that out yet). The Pd/Q interface works much better in that respect since it already allows hot-swapping the running Q script, and you can trigger that, e.g., from Emacs. A similar trick could be done with Faust plugins, too, by making a generic Faust external which just acts as a container, and loads the real plugin on its own behalf. CLAM is supposed to offer nice Faust integration (via LADSPA) already, but I haven't tried it yet. I'm looking forward to use that combination in one of my next audio programming courses, though. CLM and snd are also nice for prototyping purposes, of course, as are all the others mentioned in this thread. But for me the special thing about Faust is that it's purely functional to boot and has a formal semantics. Your programs read like mathematical specifications, and that's what they are. I won't even mention the expression syntax, as I don't want to invite the 5625342th parens-versus-infix flamefest. Oops, now I did it. :) Faust isn't perfect either. For one thing, it still lacks multirate processing. And my pet peeve: the lack of a unary minus operator. ;-) What an interesting thread. Keep it going. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Frank Barknecht wrote: > Another very new contender is Vessel, a (micro)sound synthesis > package for Lua: > http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm > http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/Wakefield_MSThesis_MAT07_Vessel.pdf Looks like that thesis was done at CREATE (UCSB). Interesting, thanks for pointing that out! I know Lua a bit (heck, it even runs on my HP 50g calculator, which is quite an amazing feat), but I didn't know about the synthesis package. > Maybe Vessel can be married with Faust as well, like the Q/Faust > coupling? Faust can be made to work in any environment which provides some means to integrate (via static or dynamic linking or whatever) basic dsp components processing a stream of samples, and can provide some way to exchange control variable values. So if Lua or Vessel itself provides these tie-ins then it should be possible, but of course someone needs to write the C++ template for it. ;-) Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] 3D audio made with Clam
Pau Arumí Albó wrote: > PS: As Albert Graef said, a new release is near. It's just a matter of > finishing the multi-platform packages and documentation. Hi Pau, that's good to know! I decided to wait for the new release before trying the new Faust interface in CLAM, and I haven't even started with the Q plugin yet, as I want to finish Q 8.0 first (hopefully this spring, at long last). But I'm really looking forward to the new CLAM version... Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Fons Adriaensen wrote: > 3. All the recursive filters I tested will generate > denormals if the input is stopped or disconnected. Yes, same as with most other dsp software. And, as usual, the solution is to add a little noise in the right places, or cut off a signal which goes below a certain threshold. Denormals are a pita. I'm not aware of any general solution (except buying the right cpu), do you know one? You can't just add noise automatically to every x~y block... Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Faudiostream-devel] Prototyping algorithms and ideas
Yann Orlarey wrote: [denormals issues] > This is a real problem but it should be solved on modern intel cpu by > enabling the FTZ mode. It would be useful if the Faust guide had a brief explanation of denormals, along with instructions on how to enable FTZ with gcc and the Intel compiler, and other workarounds. Or maybe it's time to start a Faust FAQ? This problem is surely going to bite a lot of dsp newbies who start playing with Faust on the "wrong" system. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Kjetil S. Matheussen wrote:
> The second problem (besides its lack of interactivity) I have about faust
> is that is purely functional. I have programmed lots of code in purely
> functional style, and I like it very much, so thats not the issue. But, I
> feel that being forced to work in one paradigm gives me less
> possibilities.
Yep, it takes some discipline, but you also get to reap the benefits
(clear semantics, better output code).
> It would be interesting to see how the routine would
> look like in faust, if you have the time. :-)
I don't have the time to really work out all the details of your example
right now, but looking at http://www.notam02.no/~kjetism/sandysth/, the
-1 or 1 decider should be easy to do:
max_add = hslider("Max add", 0, 0, 100, 1);
d(y,f,pc) = e(y,f,pc) ~ _;
e(y,f,pc,d) = select2(abs(y) < 1, -1*sgn(y),
select2(abs(f) <= max_add/100, -1*sgn(f),
select2(pc==1, d, -1*d)));
sgn(x) = (x>0)-(x<0);
process = d;
(Note that Faust's select2 is a bit different from if-then-else, it has
the branches reversed.)
Faust takes a bit of a different mindset. Instead of thinking in terms
of a memory cell to be changed, imagine a signal that changes over time,
then it's actually quite easy. Of course we've all been raised on a von
Neumann diet, so it takes some time to relearn how to do certain things.
But for me this is what makes Faust so much fun to use. :)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
WWW:http://www.musikinformatik.uni-mainz.de/ag
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Kjetil S. Matheussen wrote: > Thanks, that was simple. Beware, I haven't tested that code. :) > But what about resampling? The main main signal usually needs to > be resampled up 5-10 times to get a decent sound. Can I do that > with faust? Something like: > > process = resample(5,d) I want that, too. :) There's no (easy) way to do resampling inside Faust right now, because Faust doesn't support multirate processing yet. I know that Yann has this on his TODO list, as we already discussed it last summer. Once multirate processing is there, adding samplerate conversion (either programmed in Faust or by calling an external C routine) shouldn't be a big deal any more. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Kjetil S. Matheussen wrote: > The last sentence was extremely bad formulated. I ment that > the syntax for accessing faust needs to be different, because > programming in snd is s-expressions based. So what you need is an unparser for s-expressions that produces Faust's infix syntax, this shouldn't be hard. > This whole operation shouldn't take more than a few ms. Hmm, the Faust compiler needs its time, as does the C++ compiler. I don't think that you can achieve that right now. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Stéphane Letz wrote: > The LLVM backend based approach may improve the situation : http:// > www.grame.fr/~letz/faust_llvm.html, the day it will work ((-: That will enable you to skip the C++ compilation, but Faust still does a lot of stuff behind the scenes, rewriting expressions to normal form, optimizing code, etc. I found that Faust itself can take seconds to compile a source with no more than a few dozen lines. That has improved a lot during the 0.9.9.x series, but still... But I agree with Kjetil that having an interactive interface via snd would still be useful. Who cares if it takes a few seconds after editing the source until you can actually use the component? It's not as if we want to use Faust for live coding on the stage, do we? ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Prototyping algorithms and ideas
Fons Adriaensen wrote: > Won't be easy I'd think. Both resampling and fractional > sample delay lead to the same problem with different > constraints - interpolation. Sure. But what I meant is that it will then at least be possible to interface to such algorithms, whereas now there's no way to deal with streams at different rates within the same Faust program. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] starting out with tux audio
AlgoMantra wrote: > I know that website, Jens... and a good bit of Microsound theory. I also > have Curtis Roads' insane book. I'm looking > for ways to make grains and play clouds using /dev/dsp and C code. > I should be better off experimenting myself than looking for help, > but a little cheating never hurt anybody ;) Well, it can be fun to poke around with a little bit of C code, but in the case of GS this probably won't get you very far unless you really get serious and write your own realtime synthesis engine. Which isn't easy. So why not use SuperCollider? SC is well-suited for this kind of application because of the ease with which you can allocate massive amounts of voices dynamically. All the realtime audio and control stuff that you need is already there, and you can still program everything the way you want it, rather than using some ready-made GS software. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] starting out with tux audio
AlgoMantra wrote: > But I _would_ rather write my own realtime synthesis engine. Well, then go for it. :) Sorry, I didn't understand that C was an absolute requirement. > And I would never even dream of using ready-made GS software. > That kills the whole point, doesn't it? Yes sure, exactly my point. > Oh and, 6 months ago I wanted to do > all this in Python, which then was the only language I knew. Just my luck > that sound in Python is/was in a deplorable state. You can use SC from any language that has an OSC interface (like C, Python, Haskell, Q, ...), no need to program in SC language if you don't want to. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] OT: alternative fuel for cars [was: Re: Car engine sound emulation for future electic cars. ideas ?]
Patrick Shirkey wrote: > Exploding/burning water has been done and it is definitely absolutely > possible. Sure. Getting net energy from that is the hard part. :) Reminds me of a story by Stanislaw Lem where Prof. Tarantoga is visited by one of those crackpots who's invented a perpetuum mobile, claiming that it's a real device. He keeps on turning the handle on that thing, "See, it's working! I don't have to turn the handle, just ignore that, it would work anyway!" Hilarious. Anyone else know that story? So what's next? Quadrature of the circle? P=NP? Proof of the Riemann hypothesis? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LAC2009: Paper deadline extended!
Frank Neumann wrote: > This mail is to inform you that the paper submit deadline for the LAC2009 > (Linux Audio Conference)(1) has been extended to January 29th, 2009. Maybe the conference website should be updated accordingly? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GIl, python, threading, and IPC
David Robillard wrote: > Python is nowhere even remotely near realtime safe, unless you're doing > some clever allocation stuff etc.? I don't know the internals of the CPython interpreter, but I'd say it's safe to assert that Python does its own memory management. Python should be perfectly capable of doing control rate processing, for suitable values of "control rate" of course. :) Python works fine as a control plugin in Pd, but that's easier since Pd always runs single-threaded. I agree with the OP's analysis that it's the multithreading in the host environment which kills it in this case, because CPython's GIL effectively serializes all processing done in the interpreter. That means that you can't take advantage of multiple cores and the context switching overhead becomes prohibitive in a low-latency setting. OTOH, migrating the different Python threads to different processes, to work around the GIL, makes it hard to have the audio threads share data structures with the corresponding Python threads. I'm not a Python expert, but I see that Python can handle data in shared memory, maybe that would be a solution? It would still require synchronization on the shared data, of course, but the rest of the processing in Python could then be done in a lockfree fashion, no? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAA] [ANN] guitarix-0.05.0-1 released
hermann wrote: > guitarix is a simple Linux Rock Guitar amplifier and is designed > to achieve nice thrash/metal/rock/blues guitar sounds. Cool stuff. Congrats on the new release. :) > : Albert Graef > http://www.musikwissenschaft.uni-mainz.de/~ag/ag.html Also see http://q-lang.sourceforge.net/examples.html#Faust for some of my own Faust examples. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Kim did the switch to Linux
Frank Barknecht wrote: > here's an excellent read about Kim Casone (of .microsound and this list, too) > switching from Mac to Linux: > > http://createdigitalmusic.com/2009/08/04/linux-music-workflow-switching-from-mac-os-x-to-ubuntu-with-kim-cascone/ > (URL in one line) Yup, that also hit the Slashdot frontpage last night. http://linux.slashdot.org/article.pl?sid=09/08/04/2131224 -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Selectable limit for polyphony of virtual synth
hollun...@gmx.at wrote: > One obvious question there is: > what should the synth do when it reaches the limit? > There are several things that are possible and afaik implemented in > synths. It could drop the first note played, or the highest, or ... Well, that's called voice stealing. Most synths do it, if they don't have dynamic voice allocation. Usually, you assign voices in a round robin manner, and the oldest note has to go when you're running out of voices. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]
Frank Barknecht wrote: > It does pitch detection inside of Pd to tune the transformations to the pitch > played, so you still get a bit of latency (pitch detection is made on blocks > of > 1024 samples afaik.) Hmm, 20 msecs at 48KHz doesn't sound too bad. The earliest pitch trackers on MIDI guitars had some 250 msecs latency IIRC, now those are a real challenge to play. ;-) (Robert Fripp did it, though.) I actually have one of those hexagonal pickups (a Korg ZD3) retrofitted on a Fender Stratocaster, but it uses a custom interface. Does anyone here know how to extract the six individual audio signals from these? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]
Hi Victor! victor wrote: > Do you mean hexaphonic? Does it use the 'old' GR roland connector? Yes, that's what I meant. :) The ZD3 is supposed to be similar to the Roland GK-1 (http://www.joness.com/gr300/korgz3.htm), but the pin assignments (24 pins) are not exactly the same, so I'm not sure whether those adapters you mention will fit. Of course I could just take the MIDI output with pitch bends on six MIDI channels and translate that back to the frequencies. The tracking of the Korg Z3 is pretty good, and it has an astonishing low latency for a device of its age. But I thought that it would be cool to actually get at the audio signals themselves, and not having to carry around that bulky Z3 unit all the time. > I saw somewhere you could get a converter from that (19-pin?) to the > modern (12-pin?) connector, which can either be split or you can buy > a rather expensive box to get 6 outs. I'll try to find where that was. That would be much appreciated, thanks! Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [PD-announce] smeck (6ch guitar processing patch) released]
Klaus Kosten wrote: > No this isn't true. Even the old GR-700 had about 30 ms, and modern > converters get hardly below 20 ms. See > http://www.joness.com/gr300/MIDI_SPEED.htm Ok, then I didn't remember correctly. :) Thanks for the link. Also, thanks to everybody else for the tips! Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Auto-wah plugin
Guido Scholz wrote: > DESTDIR usage is only for building packages; there is no purpose for > someone bypassing his packaging system and installing it directly from > source to use this variable. But this procedure may be unhealthy. DESTDIR is very useful for developers, too. It provides you with an easy way to check your 'make install' target. And it can be useful for end users as well. E.g., you might want to first do a staged install to see what exactly gets installed and where. (With simple packages, make -n install will give you that information, but that's not generally true.) Also, I don't know how often I cursed at a source package which provided no uninstall target; in that case a staged install gives me the information I need to uninstall the package. Source packages which provide neither DESTDIR nor 'make uninstall' can be a royal pita to deal with, usually I won't touch them with a 5 foot pole, except maybe on a "scratch" system that's hosed anyway. So, DESTDIR is pretty much standard these days, it is easy to support and makes developers, users *and* packagers happy, I think that every source package should have it. :) My 2c. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Realtime MIDI programming?
Harry Van Haaren wrote: > And I'd advise you to start with "normal" scheduling (I've never coded > an RT app, but MIDI apps works > 100% realtime for me without any upgrading of priority). That may work if you have enough spare cpu power, but otherwise you may get a lot of jitter which really hurts with fast pieces (lots of MIDI messages at a fast tempo). It's really not that hard to get realtime scheduling priorities on recent Linux systems. I wouldn't want to run any computer music application without that. But maybe RtMidi already does that behind the scenes? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Realtime MIDI programming?
victor wrote: > As an alternative, you can use PortMIDI. It's a fairly simple API and > I would recommend it. Seconded. It's very portable as well, and wrappers exist for many programming languages (or are easy to build, as it's just plain C). Another thing that PortMidi has going for it, is that in conjunction with PortTime it supports timing (and scheduling), an important feature which RtMidi seems to lack entirely. (Yes, I noticed that Carlo didn't ask for that, but he's probably going to need it anyway, sooner or later.) Also, I just noticed that the PortMedia project finally offers PortSMF to read and write standard MIDI files, too, I always missed that piece. ;-) Talking about Midi libraries, the venerable MidiShare is still the most complete and feature-rich I've seen. Alas, it's 32 bit only and requires a kernel module on Linux. The Grame people have moved on to other things (Faust, most notably), and so this library is quickly falling victim to bitrot now. :( If there's a young Linux audio programmer interested in MIDI and looking for a project he can cut his teeth on, porting MidiShare to 64 bit and getting rid of the kernel module would be a very worthwhile endeavour! Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Realtime MIDI programming?
David Robillard wrote: > Casting my predictable vote for Jack MIDI :) Hi David, is there a nice introduction to Jack MIDI available somewhere? I guess that there ought to be a LAC paper about it, but a quick Google search didn't turn up anything useful. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Realtime MIDI programming?
Arnout Engelen wrote: > There is some simple example code available at the jackaudio wiki though: > http://trac.jackaudio.org/wiki/WalkThrough/Dev/SimpleMidiClient Thanks, that looks pretty straightforward. I guess that to output MIDI from another thread one is supposed to use a ringbuffer which is read by the Jack callback, or is there a better solution for that? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Realtime MIDI programming?
Paul Davis wrote: > but keep in mind that, just as with audio, JACK is "encouraging" "RT > design" in which you do the work associated with a particular audible > time as close to that time as possible. of course, this doesn't apply > to playback of MIDI from disk, but if you're doing algorithmic > composition, the long term goal is to encourage people to write the > same that they do with audio synthesis: JACK says "its time to > generate data for the next block" and the app does it right there and > then. obviously, some mileage may vary :) Yes, I understand. But I'll have to find out whether it's feasible in my case (Jack module for Pure). Guess I'll take a look at other language bindings and see how they do it; if it works with py-jack, then Pure should certainly be able to do that, too. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] Hello World: linuxaudio.org on a new Machine
Robin Gareus wrote: > Anyway, there may still be a few minor glitches as we continue to tweak > the system during the next days. - but don't hesitate to contact us > should you experience some unexpected behaviour with the site. Robin, while you're at it, maybe you could also have a look at http://quicktoots.linuxaudio.org/. Links 1-4 in the Topics navigation bar seem to be dead. Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LAC "Tools" round-table wrapup
Hi Robin, I can't get to the wiki page linked to in your previous post, so here are some hopefully useful remarks. Robin Gareus wrote: > In partictular the "multi-rate", "sync" & "async" need clarification. - multirate: The ability to deal with synchronous streams of (audio) data at different samplerates. - sync: synchronous (sample-based) processing at fixed samplerate(s) (typically audio and video). - async: asynchronous (event-based) processing (typically MIDI, OSC and the like). Note that we didn't have experts for all the mentioned programs on board during the discussion (most notably, the supercollider people were absent since they had a session in parallel), so it can't hurt if the feature matrix is proofread by as many eyeballs as possible. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LAC "Tools" round-table wrapup
Robin Gareus wrote: > really? well we had a 30 min outage this afternoon (CEST) but the site's > online: > http://wiki.linuxaudio.org/wiki/tools_comparison Well, then I must have tried during the downtime. ;-) Works for me now. > - batch (does it mean app can be called (headless) from a batch script, or > that the app itself offers batch processing) That was supposed to mean offline (audio) rendering, so it's the latter. > - embed. means embedded or embeddable? The latter. (I.e., app is available in the form of a library which you can link into your own programs.) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] GPL and plugins
Victor Lazzarini wrote: > I think this is the closest to the scenario I am envisaging. There is a > host, which is non-Free and commercial, currently using a non-Free > plugin, which is packaged with it. This non-Free plugin gets substituted > by a Free plugin, which is free because, amongst other things, it links > to a GPL dynamic library. Is this breaking the original GPL license of > the dynamic lib the plugin links to? Yes. IANAL and all that, but the GPL is very clear on that, see e.g.: http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF In fact, library authors decidedly use the GPL (rather than the LGPL which allows linking against proprietary software) to prevent unsolicited use of their libraries in commercial software. Of course, the vendor can always ask you and the author(s) of the 3rd party library for a commercial license which allows it to distribute the plugin with its commercial program. You can also put an exception into your plugin license which specifically allows linking against the commercial program, but you'd still have to ask the author(s) of the GPL'd library for the same kind of permission. HTH, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] GPL and plugins
Paul Davis wrote: > If [ ... ] ***WE BELIEVE*** they form a single program, which must be > treated as an extension of both the main program and the plug-ins. Well, this is a FAQ, not expert legal opinion. But according to the FSF the intent of the license is that if A and B are linked together in the same program (no matter how that happens, static or dynamic linking, dlopen etc.) and B is GPL'ed then the combination A+B becomes a "derivative work" and is thus subject to the terms of the GPL. At least that's how I read the GPL FAQ. YMMV, but from what I've read in various discussions, e.g. at license-disc...@opensource.org, I believe that this interpretation is right, or at least the one intended by the FSF. No idea whether this would stand up in court. In any case, as a vendor who wants to distribute such a combination, I would either ask the authors for explicit permission or seek legal advice. > i don't believe that this is really the same thing. yes, this > definitely the point of releasing a library under the GPL. but > libraries are not plugins. No, but if your plugin is provided in the form of a dynamically loadable module, then according to the FSF it's to be treated just like a library linked into your program. It doesn't matter whether the linking happens at compile time or at run time. Otherwise a commercial vendor could just turn GPL'ed libraries into "plugins" and happily sell its non-free programs using those. That's surely not the intent of the GPL. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] GPL and plugins
Luis Garrido wrote: > Ok, again this is my personal, legally unqualified opinion, but it > would seem then that the LGPL might be perhaps the solution for your > case. Yes, but if Victor uses a GPL'd library for his plugin then the combination of the plugin and the library would still be GPL'd. So that doesn't make a difference in this case. Unless he can find an LGPL'd replacement for the library, too. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] twice as loud
lieven moors wrote: > ...continuation of truncated mail (does anyone know why this happens?) Probably it's the second "From" line; looks like your mail client is confused by this. Concerning your question: As other have remarked, that is a very intricate question which is studied in psychoacoustics, so one of the requisite textbooks on the subject (like Roederer's "Psychophysics") might be helpful. Conventional wisdom (based on psychoacoustic experiments) has it that a 10 phon increase (i.e., 10dB SPL, corrected for frequency-specific sensitivity using the Fletcher/Munson curves or some variation of that) means double loudness for many people (on the average). But of course that doesn't mean that you can just add signals until you achieve a 10 phon increase and get something twice as loud. If you're adding signals then you also have to consider masking effects (basically, spectral components hitting the same critical band on the Cochlea), so you'll need a psychoacoustic model (same as what gets used for lossy compression) to get it sorted out. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] twice as loud
lieven moors wrote: > On 07/22/2010 11:25 PM, Albert Graef wrote: >> lieven moors wrote: >> >>> ...continuation of truncated mail (does anyone know why this happens?) >>> >> Probably it's the second "From" line; looks like your mail client is >> confused by this. >> >> Concerning your question: As other have remarked, that is a very >> intricate question which is studied in psychoacoustics, so one of the >> requisite textbooks on the subject (like Roederer's "Psychophysics") >> > Thanks for the pointer. I'll see if I can find a copy... That's the one that I mean (most recent edition): http://www.amazon.com/Physics-Psychophysics-Music-Introduction/dp/0387094709/ref=dp_ob_title_bk If nothing else, it should point you to the original literature that's relevant to your question and see how these people went about their experiments. > Do you think there is a direct connection between frequency-specific > sensitivity, and the SPL range the ear can tolerate for specific > frequencies? That's in the F/M curves as well. There have also been experiments to identify the ranges that are relevant to language and music. Indeed there has been *lots* of scientific work done in this area since the 1960s. Of course all these results are statistical as they relate objective physical measures with subjective levels of stimuli, but that doesn't mean that it's all hogwash. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Project proposition: llvm based dsp engine
Maurizio De Cecco wrote: > Surely a contribution to the discussion by the Faust people would > be welcome; and even more than to the discussion :->. By the way, they > do something with LLVM, but i do not know exactly what (Faust is included > in the list of projects using LLVM). Thanks to Stephane Letz' work, Faust has had an LLVM backend for some time. (You need to get the faust2 branch from the Faust git repo for that, however.) Faust2 supports the creation of both LLVM assembler and bitcode. The latter can be loaded and executed directly by other LLVM clients (such as my own Pure, which also sports inlining of Faust programs in Pure scripts now). Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Warming up for LAC2011
On 05/03/2011 11:15 PM, Victor Lazzarini wrote: still to be confirmed, but it looks like we'll meet at the Roost (at the restaurant at the back), maybe around 7. The Roost is easy to find: in front of the Garda Station! Great, I'm looking forward to that. See you guys on Thursday! Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] What sound cards are recommender by developers? I'll order next week!!!
On 05/23/2011 09:59 AM, Jeremy Jongepier wrote: Not much to recommend, basically only one candidate at the moment afaik: http://www.m-audio.com/products/en_us/FastTrackUltra8R.html This looks interesting, and I'm tempted to buy one, too, but how well is it supported by recent ALSA versions? Google turns up very mixed results. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] What sound cards are recommender by developers? I'll order next week!!!
On 05/23/2011 11:43 AM, Jeremy Jongepier wrote: No idea :( This M-Audio card always needed a patch. More info here: http://www.linuxmusicians.com/viewtopic.php?f=6&t=1581&start=15&st=0&sk=t&sd=a This post contains the specific patch: http://www.linuxmusicians.com/viewtopic.php?f=6&t=1581&start=15&st=0&sk=t&sd=a#p8085 Jeremy, thanks for the info. I seem to recall that you also had a similar device in your workshop at LAC. What device was that? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] What sound cards are recommender by developers? I'll order next week!!!
On 05/24/2011 09:34 AM, Jeremy Jongepier wrote: That was a Focusrite Saffire Pro 10 IO FireWire device. That one looks nice. Unfortunately, it seems that it's discontinued, and models 24 and 40 are still marked as experimental (need ffado from svn) on the ffado website. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] ComputerHistory: Max Mathews & John Chowning
This was just posted on the YouTube ComputerHistory channel: Max Mathews & John Chowning - Music Meets the Computer (in conversation with Curtis Roads) http://www.youtube.com/watch?v=Hloic1oBfug This was already recorded in 2004, so maybe some of you have already seen it. For the others (including myself) it should be interesting to watch. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] TYOQA: Qtractor 0.5.0 - The Alpha Zulu awakening!
On 07/22/2011 06:20 PM, Rui Nuno Capela wrote: Now comes the mighty corrosive one: I'll be off on vacation soon. Summer is waiting for me. And I just hate to miss that kind of deadline. Woohoo! Hi Rui, thanks a bunch for the new version and have a nice vacation! :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] ANN: pd-faust 0.1
pd-faust is my latest stab at making the integration of Pd and Faust as simple and painless as possible. For those of you who've used my utilities for Faust and Pd before, pd-faust integrates the functionality of faust2pd and pure-faust into a collection of Pd objects written in the Pure programming language. It also sports the following major improvements over faust2pd: - Reload Faust modules at runtime and have the Pd GUI of the Faust dsp regenerated automatically and instantly. - The metadata in Faust programs is interpreted to adjust the GUI layout in a faust2pd-compatible fashion. - MIDI/OSC controller mappings are provided for the 'midi' and 'osc' metadata tags in the Faust source. - Built-in MIDI sequencer and OSC recorder which syncs MIDI and OSC playback and provides an OSC-based controller automation facility for all Faust dsps in a Pd patch. So in other words it's the Swiss army knife for Faust development in Pd. ;-) If you're into Faust and Pd, I hope that you'll find it useful. Bug reports and other feedback are appreciated. A brief overview is available here: http://code.google.com/p/pure-lang/wiki/Addons#pd-faust The obligatory screenshot: http://wiki.pure-lang.googlecode.com/hg/pd-faust.png Detailed documentation (including installation information): http://docs.pure-lang.googlecode.com/hg/pd-faust.html pd-faust is compiled to a native Pd object library which can be loaded with Pd's -lib option as usual. Note that besides Pd, Faust and pd-faust itself you'll also need the Pure interpreter and a couple of Pure addon packages to build and run this software. Please check the documentation linked to above for details. All the Pure-related downloads can be found on the Pure website: http://pure-lang.googlecode.com For your convenience, here are the direct download links for the required packages from the Pure project (source tarballs): http://pure-lang.googlecode.com/files/pure-0.50.tar.gz http://pure-lang.googlecode.com/files/pd-faust-0.1.tar.gz http://pure-lang.googlecode.com/files/pd-pure-0.15.tar.gz http://pure-lang.googlecode.com/files/pure-faust-0.6.tar.gz http://pure-lang.googlecode.com/files/pure-stldict-0.2.tar.gz You'll also need a recent version of Pd (0.43 has been tested) and Faust from git (0.9.45 and 2.0.a3 are both known to work fine). Happy holidays, Albert P.S.: Sorry for the excessive cross-posting, but the nature of this project which interfaces between three different environments, each with their own communities, made this seem appropriate. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 12/28/2011 06:01 PM, Rui Nuno Capela wrote: Qtractor 0.5.3 (delta whisky) drops from angels share! Hi Rui, I just love your release announcements. ;-) And I love Qtractor, too. I've been running into two issues with MMC sync recently, though. First, the MMC goto messages emitted by Qtractor always have the subframe count zeroed out. Is this intentional? That way you only get a 1 frame (= 1/30th of a sec) resolution, surely it would be better to have the subframe field filled in? Second, when looping Qtractor doesn't send an MMC goto message when it returns to the beginning of the loop during playback. I'm not sure what the MIDI spec has to say about this, but e.g. Rosegarden does this. Would it be possible to have this behaviour in Qtractor, too, at least as an option? I'm running the "delta whisky" here. Many thanks in advance, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/04/2012 04:55 PM, Rui Nuno Capela wrote: that's correct. qtractor mmc-locate resolution is crippled to 30fps since eh... ever? :) Is that a polite invitation to go fix it myself? ;-) yes (or no:) qtractor does not send out any mmc-locate messages on its loop turnarounds. sorry. thinking of it, i am not sure whether that is a polite thing to do. let me think again... aha. it brings me down to this humble fact that qtractor mmc implementation is no substitute for jack-transport whatsoever... I know that qtractor does jack-transport, but unfortunately that doesn't help me since Pd is the client that I use, which has no (built-in) jack-transport support whatsoever. There might be a Pd external implementing that kind of thing, but my application needs to run in environments where just the vanilla Pd might be installed, so I wouldn't want it to depend on some obscure 3rd party plugin if I can avoid it. have you tried jackctlmmc? or is it qjackmcc? hmm, i don't quite remember... my aging memory is failing on the spot:) jackctlmmc / qjackmcc goes the wrong way round, it's an ALSA MMC slave that drives jack-transport. I'd need exactly the opposite. :) I've been googling for that kind of thing, but there doesn't seem to be any (apart from other full-blown sequencer/HDR applications). So, in the light of these observations, it still seems worthwhile to have better MMC support in Qtractor. Do you have any plans to work on this some time? slaintheva! Cheers! Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/04/2012 06:49 PM, Rui Nuno Capela wrote: the following blog post might give you a hint of how old and toy'ish is mmc support in qtractor :) it didn't change much since then :) http://www.rncbc.org/drupal/node/15 i'll take a note ntl. Ok, thanks. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/04/2012 06:53 PM, Alex Montgomery wrote: For the record, QJackMMC is an ALSA *and* JACK Midi slave, but you're right that it only listens to MMC messages and does not produce them. Maybe I should have worded that better, but what I meant was that it's an MMC slave rather than an MMC master (which is what I need). Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/04/2012 07:53 PM, Albert Graef wrote:
On 01/04/2012 06:49 PM, Rui Nuno Capela wrote:
the following blog post might give you a hint of how old and toy'ish is
mmc support in qtractor :) it didn't change much since then :)
http://www.rncbc.org/drupal/node/15
i'll take a note ntl.
Ok, thanks.
Just for the record, there's also a minor bug in
qtractorMmcEvent::locate (qtractorMmcEvent.cpp line 36). Bits 6 and 7
(counting from 1) in the hours field of an MMC locate message are used
by some software and MIDI controller hardware to encode the fps value
(00 = 24, 01 = 25, 10 = 30 drop, 11 = 30; it's the same encoding as in
the hour bytes of MTC quarter frame messages, if I'm not mistaken). So
qtractor may jump to a high offset if it receives a message where these
bits are set. Specifically, I found that this happens when I push the
"locate 0" button of the "simple mixer" preset of my Behringer BCF-2000.
I work around this by just masking out these bits for now. That works
fine if the MMC master or MIDI controller is set to the 30fps that
Qtractor uses. Patch against qtractor-0.5.3 attached.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW:http://www.musikinformatik.uni-mainz.de/ag
diff -ru qtractor-0.5.3.orig/src/qtractorMmcEvent.cpp qtractor-0.5.3/src/qtractorMmcEvent.cpp
--- qtractor-0.5.3.orig/src/qtractorMmcEvent.cpp 2011-05-15 00:03:38.0 +0200
+++ qtractor-0.5.3/src/qtractorMmcEvent.cpp 2012-01-07 16:12:03.066254980 +0100
@@ -33,7 +33,7 @@
unsigned char *data = (unsigned char *) m_data.constData();
if (m_cmd == LOCATE && m_data.length() > 4 && data[0] == 0x01) {
- iLocate = (3600 * 30) * (int) data[1] // hh - hours[0..23]
+ iLocate = (3600 * 30) * (int) (data[1]&0x1f) // hh - hours[0..23]
+ ( 60 * 30) * (int) data[2] // mm - minutes [0..59]
+ ( 30) * (int) data[3] // ss - seconds [0..59]
+ (int) data[4]; // ff - frames [0..29]
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/09/2012 04:00 PM, Rui Nuno Capela wrote:
applied. qtractor svn trunk rev.2659 (v0.5.3.4)
Thanks a bunch. :) Attached is another suggested patch against the
current trunk (r2660) to make qtractor send an MMC locate after jumping
back to the beginning of a loop. It's not perfect, but I'm posting it
anyway in case someone may find it useful.
As you can see I handled this in the timer callback of the main form
which isn't 100% accurate, but I never found it to be off by more than 1
frame, which I guess is good enough for my purposes. There are surely
better ways to do this, but I wasn't able to figure that out without
investing much more time reading the source code. Ideally, this should
be handled on the spot somewhere in the MIDI engine. I tried to add it
directly in qtractorMidiOutputThread::process(), but the read-ahead gets
in the way there, so I couldn't find a proper way to make that work. (Is
there a way in qtractor to schedule a callback exactly at the *real*
time when the play head reaches a given position? Then this would be easy.)
There are a few other situations where an MMC locate is still missing,
specifically after ending a rewind or fast-forward, but I have no idea
how to fix this without diving into the qtractor sources much more than
I did. :(
Cheers,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW:http://www.musikinformatik.uni-mainz.de/ag
Index: src/qtractorMainForm.cpp
===
--- src/qtractorMainForm.cpp (revision 2660)
+++ src/qtractorMainForm.cpp (working copy)
@@ -6167,6 +6167,7 @@
// Currrent state...
bool bPlaying = m_pSession->isPlaying();
long iPlayHead = long(m_pSession->playHead());
+ bool bRelocate = iPlayHead < (long)m_iPlayHead;
qtractorAudioEngine *pAudioEngine = m_pSession->audioEngine();
qtractorMidiEngine *pMidiEngine = m_pSession->midiEngine();
@@ -6194,6 +6195,10 @@
m_pSession->songPosFromFrame(iPlayHead));
}
}
+ else if (bRelocate) {
+ // MMC locate for loop start - ag
+ pMidiEngine->sendMmcLocate(m_pSession->locateFromFrame(iPlayHead));
+ }
}
// Transport status...
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/09/2012 10:49 PM, Rui Nuno Capela wrote: applied, slightly modified. svn trunk rev.2663 (aka. qtractor 0.5.3.5) Thanks, that was quick. :) ok. i'll have to look at it again, sooner or later ;) I'm looking forward to that, thanks again. I'm now facing a more serious issue, though: Qtractor (latest from svn) segfaults after recording audio. Start a new session, add an audio track, arm it, arm qtractor, start recording, press either the record or the stop button -> segfault. This happens every time for me. (I'm running jackdmp 1.9.8 here, if that makes any difference. Seems to work fine with Ardour3, though.) Rui, can you reproduce this? If not then I'll have to build a debug version and run it with gdb to get a meaningful backtrace. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/10/2012 12:34 AM, Albert Graef wrote: (I'm running jackdmp 1.9.8 here, if that makes any difference. Seems to work fine with Ardour3, though.) Sorry for the lousy bug report. :) Let me just add that I'm running Ubuntu 11.04 on a quadcore x86_64 cpu (AMD Phenom), if that gives any additional clues. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/10/2012 10:31 AM, rncbc wrote: a debug version (./configure --enable-debug) should dump an automatic stacktrace on segfault (via gdb)... This gives me a "ptrace: Operation not permitted." But running the program in gdb I get the attached backtrace. (Running r2665, latest from trunk there.) does this crash-on-record happen with prior builds, before your patching suggestions ? Yes, it's already in the 0.5.3 release. The stock Ubuntu 11.04 version of qtractor (0.4.8) works fine, though. I also get segfaults when closing the GUI of LV2 plugins (e.g., calf organ). I don't get these with 0.4.8 either, and they work fine with Ardour3 as well. But maybe I should start filing proper bug reports now. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag #0 0x in ?? () #1 0x004454ea in qtractorAudioBus::latency_in (this=0x1031e70) at qtractorAudioEngine.cpp:2422 #2 0x0045f031 in qtractorClipCommand::addClipRecord (this=0x11c0990, pTrack=0x1194650, iFrameTime=101376) at qtractorClipCommand.cpp:282 #3 0x005ada8b in qtractorMainForm::setRecording (this=0x7fffd6c0, bRecording=false) at qtractorMainForm.cpp:4933 #4 0x005ad792 in qtractorMainForm::setPlaying (this=0x7fffd6c0, bPlaying=false) at qtractorMainForm.cpp:4878 #5 0x005aca33 in qtractorMainForm::transportStop (this=0x7fffd6c0) at qtractorMainForm.cpp:4571 #6 0x006609b5 in qtractorMainForm::qt_metacall (this=0x7fffd6c0, _c=QMetaObject::InvokeMetaMethod, _id=124, _a=0x7fffc0e0) at .moc/moc_qtractorMainForm.cpp:484 #7 0x7173f5f8 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #8 0x71c12122 in QAction::triggered(bool) () from /usr/lib/libQtGui.so.4 #9 0x71c1230f in QAction::activate(QAction::ActionEvent) () from /usr/lib/libQtGui.so.4 #10 0x71fdb46a in ?? () from /usr/lib/libQtGui.so.4 #11 0x71fdb71c in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/libQtGui.so.4 #12 0x720979ba in QToolButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/libQtGui.so.4 #13 0x71c69cc8 in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4 #14 0x71c189f4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #15 0x71c1ddc3 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #16 0x7172a49c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #17 0x71c19a1d in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) () from /usr/lib/libQtGui.so.4 #18 0x71c9b190 in ?? () from /usr/lib/libQtGui.so.4 #19 0x71c99ab7 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/libQtGui.so.4 #20 0x71cc2842 in ?? () from /usr/lib/libQtGui.so.4 #21 0x72986bcd in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #22 0x729873a8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x72987639 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x717553ef in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/libQtCore.so.4 #25 0x71cc24de in ?? () from /usr/lib/libQtGui.so.4 #26 0x71729882 in QEventLoop::processEvents(QFlags) () from /usr/lib/libQtCore.so.4 #27 0x71729abc in QEventLoop::exec(QFlags) () from /usr/lib/libQtCore.so.4 #28 0x7172decb in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #29 0x00431620 in main (argc=1, argv=0x7fffe178) at qtractor.cpp:411 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/10/2012 07:43 PM, Rui Nuno Capela wrote: does the backtraces you get always point to the same spot? #1 qtractorAudioBus::latency_in at qtractorAudioEngine.cpp:2422, which in fact is the call to jack_port_get_latency_range() ? Yes. This is 100% reproducible for me. Maybe an SMP-related issue? I'll see whether installing jack1 instead helps. it depends on how new are the build of those calf plugins... Latest. I grabbed them from Dave's svn repo and built them today. recently the default build changed from using the good old lv2_external_ui extension into the troublesome lv2_gtk_ui. They all work fine with qtractor 0.4.8 which just seems to ignore the fancy new GUIs and creates its own instead. Is there a way to get that behaviour in the latest qtractor? you may get some different results if you build qtractor with the new lilv stack (--enable-lilv) instead of the old slv2 but anyway, I wanted to try that next, but lilv doesn't build against the LV2 version that I have here (the version that ships with Ubuntu 11.04 is still 3.0). I'm not sure what I need to install to get lilv up and running, as the dependencies aren't documented anywhere. The Qtractor README file thankfully mentions that I need those serd and sord libraries, but that doesn't seem to be enough, running waf configure still complains that it can't find lv2/lv2plug.in/ns/lv2core/lv2.h which my LV2 installation doesn't have. Do I also need the latest lv2core package? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/10/2012 08:54 PM, Albert Graef wrote: I wanted to try that next, but lilv doesn't build against the LV2 version that I have here (the version that ships with Ubuntu 11.04 is still 3.0). Never mind, it was just lv2core and lv2-ui that had to be installed first. The LV2 plugins work great now! Thanks for the hint. Now I just need to get that jack-related segfault sorted out. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.3 - The Delta Whisky natural cask strength!
On 01/10/2012 09:27 PM, Albert Graef wrote: Now I just need to get that jack-related segfault sorted out. Works fine with jack1. Both jackdmp 1.9.8 and the stock 1.9.6 from Ubuntu 11.04 segfault with Qtractor 0.5.3.x. So it looks like jack2 might be to blame there, maybe the jack2 implementation of jack_port_get_latency_range() isn't SMP safe? Stephane, do you have an idea what might be going on there? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] ingen anyone?
Has anyone got ingen to work recently? I'm running all the latest stuff from Dave's svn repo here, but I'm getting bitten by this bug: http://dev.drobilla.net/ticket/798, which makes it rather unusable (loading patches doesn't work, neither from the command line nor inside ingen). I went back as far as r3829, which still had the same bug. Can anyone recommend a revision that works? I'd really like to give it a go, but without the ability to load patches it's only half the fun. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ingen anyone?
On 01/13/2012 11:13 PM, Albert Graef wrote: Has anyone got ingen to work recently? I'm running all the latest stuff from Dave's svn repo here, but I'm getting bitten by this bug: http://dev.drobilla.net/ticket/798, which makes it rather unusable (loading patches doesn't work, neither from the command line nor inside ingen). Never mind, I fixed it myself. Suggested patch can be found in the above ticket, if anyone suffers from the same problem. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ingen anyone?
On 01/14/2012 09:53 PM, David Robillard wrote: Fixed in trunk. Ingen and Patchage in svn are a bit more flaky than usual lately... Thanks. Yes, even with the latest revision I still have some random crashes when saving patches, and sometimes the engine apparently dies and leaves ingen with no sound so that I have to restart it. I'll file tickets for these as soon as I find a way to reproduce them. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Luppp live looper
On 01/14/2012 11:36 PM, Harry van Haaren wrote: I guess the version of libconfig is wrong... I've got version 1.4.8 here, and its compiling fine. I've checked the libconfig site for version info as to what version I need to depend on for the getFile() function, but I couldn't find relevant info. With that the compile goes through, but executing ./run.sh I get: Luppp 2.0 Top() BPM = 127 Creating MASTER AudioTrack ID: -1 Last used dir = /home/ag Time:process() doing 4th list! terminate called after throwing an instance of 'Glib::FileError' Aborted (Running Ubuntu 11.04 here, but with the latest lv2/lilv from svn installed.) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Luppp live looper
On 01/15/2012 12:23 AM, Harry van Haaren wrote: On Sat, Jan 14, 2012 at 3:16 PM, Albert Graef mailto:dr.gr...@t-online.de>> wrote: terminate called after throwing an instance of 'Glib::FileError' Fixed in git. Thanks for the report, wasn't copying resources into the .build directory. No dice. I have the latest from the devel branch and at the end of the build it does copy some stuff now: Copying resources... Copying src/ui.glade to .build/ Copying src/headphones.png to .build/ Copying src/lupppIcon.png to .build/ The files are in .build all right, but I still get the same error. Some other stuff missing? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Luppp live looper
On 01/15/2012 01:00 AM, Harry van Haaren wrote: Just committed a fix for the fix I done earlier on today, must be getting tired ;) Works now, thanks. Currently it *only* attempts to load GUI resources from the same dir as the binary. Understood. Samples & other resources can be anywhere. I'll try and get a little Install & Current usable features tutorial thing up in the next couple of days. That will definitely be needed. :) I was able to load a sample into a track, but I didn't get much past that. Anyway, the application looks promising, please keep us posted! Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS LV2 plugins: Version 0.0.6
On 01/15/2012 12:57 PM, Aurélien Leblond wrote:
The GPL is v2 in the code as it's the same one as coming from AMS.
As Ralf rightfully remarked, you have to check the original code for the
exact wording of the license. If it's GPLv2+ ("GPLv2 or later") you're
free to choose either GPLv2+ or GPLv3+, as the authors explicitly gave
you the permission to do that.
Unfortunately, the AMS manpage indeed seems to indicate that it is
licensed under GPLv2 only as the "or later" clause is missing there, and
I can't find any other statement in the latest released tarball or on
the website clarifying the license.
So your code probably needs to be licensed under GPLv2 only. GPLv2 is
still fine as a license (unless you're bothered by modern absurdities
like DRM, tivoization and software patents, that is). It poses a problem
if people want to use your code in their GPLv3+ projects, though -- they
can't.
So my interpretation is that if you'd like to relicense under GPLv3+
you'll have to contact Matthias Nagorni and get his explicit written
permission. According to the AMS manpage he's the only copyright holder
and I can't find any other copyright notices in the code, even though
there's no doubt that AMS has had a lot of contributions from Fons and
other people.
If I'm not mistaken, Matthias has long left for greener pastures,
though. Matthias, are you still lurking here? Maybe you can clarify the
license?
- I'm not even sure of what is the difference between the version 2 and
the version 3 of the GPL.
There's plenty of information about that on the web. From the horse's
mouth: http://gplv3.fsf.org/rms-why.html.
- The code is ported from AMS. Am I aload to change the license just
like that?
The license statement along with the license text tells you exactly what
you're allowed to do. In this case, as the "or later" clause is missing,
you're bound by the terms of the GPLv2, as set forth in the accompanying
COPYING file. Specifically, term 2 of the license tells you that you
have to relicense your derived work under the terms of the same license.
Disclaimer: IANAL either and this isn't legal advice, so when in doubt
consult your lawyer. ;-) But this is how I read the license terms of
AMS, to the best of my knowledge.
HTH,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW:http://www.musikinformatik.uni-mainz.de/ag
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS LV2 plugins: Version 0.0.6
On 01/15/2012 05:45 PM, Fons Adriaensen wrote: See Help->About for the list of authors. Right, the About dialog at least contains some up-to-date copyright notices. But it doesn't detail the exact license terms either, so presumably that would still be GPLv2 only. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS LV2 plugins: Version 0.0.6
On 01/15/2012 06:36 PM, Ralf Madorf wrote: So "GPLv2" without a "+" or similar indeed seems to stand for "GPLv2 only". There's no doubt about this. I've had to deal with code lifted from projects which, for whatever reason, are still stuck with GPLv2, such as Gnumeric. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS LV2 plugins: Version 0.0.6
On 01/15/2012 06:12 PM, Brendan Jones wrote: Vesrion 2.0.1 license does include the 'and later' clause in the COPYING file. That item just explains the wording to be used if you want GPLv2+. But in this case the authors didn't. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] ANN: faust-lv2 0.1 released
(Sorry for crossposting.) faust-lv2 is an LV2 architecture for the Faust programming language (http://faust.grame.fr/), which lets you compile Faust programs to LV2 plugins ready to be used with any LV2 host. It supports both effect (audio->audio) and instrument (midi->audio) plugins. The package includes the Faust LV2 architecture files, a few Faust examples, and generic waf scripts for building and installing the sample plugins. faust-lv2 can be downloaded from its project website at http://faust-lv2.googlecode.com. Here's the direct download link to the source tarball: http://faust-lv2.googlecode.com/files/faust-lv2-0.1.tar.bz2 Documentation is available in the package (README file) and on the website (http://wiki.faust-lv2.googlecode.com/hg/doc/_build/html/index.html). This includes detailed installation and usage instructions. faust-lv2 0.1 is the initial release which has been tested on x86_64 Linux with jalv, Ardour3 and Qtractor, using lilv as the LV2 host library. You'll also need fairly recent versions of Faust (0.9.46 or later should do) and the LV2 framework (available at http://lv2plug.in/). Other LV2 hosts should work as well. Unfortunately, that doesn't include zynjacku/lv2rack right now, apparently because of some bugs or incompatibilities with the latest LV2 release. Nedko, maybe you could check https://gna.org/bugs/?19282 some time, thanks. :) Enjoy! :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAA] ANN: faust-lv2 0.1 released
On 02/01/2012 12:16 PM, rosea.grammostola wrote: Interesting. Would be nice if you could use SuperCollider code (synths) as LV2 plugins too. Or is it naive to think that such a LV2 plugin (supercollider-lv2) would make much more sofsynths available for the linux platform? That's certainly possible. But the synthdefs are only part of the story. Many SC instruments are highly customized and dynamic networks of signal processing components driven by sclang code. I'm not sure how you would map those to standalone components in an LV2-based environment where audio and control ports are (mostly) static. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 implementer poll (event buffer)
On 02/06/2012 12:43 AM, David Robillard wrote: If anyone has any other gripes/suggestions for the event extension, now's the time to make them heard. Speak now or forever hold your peace, etc. AFAICT I don't use any of the items that you mentioned. P.S. I have avoided the "why does event need to be replaced" part to keep it to the point, but if anyone is curious, I can explain I'm curious. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] DrMr: a new lv2 sampler/drum machine plugin
On 02/13/2012 05:20 PM, Nick Lanham wrote:
I've written a new sampler/drum machine lv2 plugin called DrMr. You can
find it here: https://github.com/nicklan/drmr
Very nice, thanks!
I hope people find it useful, and as it's rather new code, bug reports
are of course very welcome.
One thing I noticed: There's no tilde expansion in opendir(). If you
want to make the tilde paths for the drumkits work then you'll have to
use something like wordexp() or just substitute getenv("HOME") for the
tilde before passing the path to opendir().
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW:http://www.musikinformatik.uni-mainz.de/ag
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] DrMr: a new lv2 sampler/drum machine plugin
On 02/13/2012 05:20 PM, Nick Lanham wrote: I hope people find it useful, and as it's rather new code, bug reports are of course very welcome. Two more nitpicks: 1. If the host's samplerate (as given by the LV2 instantiate() callback) differs from the samplerate of the wave files, the samples sound wrong (well, at least different from what you hear with the same drumkit in hydrogen). To avoid that, you have to resample the waves on the fly when loading them; libsamplerate does that kind of thing. 2. If you export a sequence from hydrogen as midi, you get midi notes starting at C2 (36), whereas drmr's midi mapping uses the octave starting at C4 (60). It's a minor thing, as you can easily transpose the notes, e.g., in Qtractor after importing the midi from hydrogen, but it would be more convenient if drmr used the same midi mapping as hydrogen itself. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] DrMr: a new lv2 sampler/drum machine plugin
On 02/14/2012 10:58 AM, Alexandre Prokoudine wrote: That's a quite awesome thing even in its infancy. A small nitpick: it would be nice reading user's drumkits directory, i.e. ~/.hydrogen/data/drumkits. That's a bug (see my previous post), but easy to fix. If anyone is interested, I can post the necessary changes here. Other than that, do you have plans adding UI for basic management of drumkits so that users would be able to add/remove instruments and save drumkits? You can easily do that in Hydrogen itself, so why bother? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] DrMr: a new lv2 sampler/drum machine plugin
On 02/17/2012 06:01 PM, Sebastian Moors wrote: We have already a very modular architecture, and i believe that it would be possible to create a shared lib for the reading of drumkits without big trouble. The playing/processing samples part is definitely more complicated. I think that Nick has nailed the reading of the drumkits already. So we should be concerned with the more advanced parts. Besides the drumkit editing (which I can also do with Hydrogen itself), I think that it would be nice if the non-destructive cutting and time stretching of samples implemented by Hydrogen's new sample editor would be available in DrMr. However, when I save a drumkit in which I have edited the layers in this way, Hydrogen doesn't seem to record those changes in the drumkit. Apparently, those changes are only stored in the song files, at least with the 0.9.5 and 0.9.6svn versions available at https://launchpad.net/~kxstudio-team/+archive/hydrogen/ that I tried. Is that by design, or are there plans to change this in the 0.9.6 version of Hydrogen? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] DrMr: a new lv2 sampler/drum machine plugin
On 02/18/2012 12:05 AM, m.wolkst...@gmx.de wrote: if i designed the hydrogen-sample-editor the main concept was to make them non destructive and bind all sample settings to h2 song-files. Ok, so it's by design. That's what I wanted to know, thanks for clarifying this. I can also understand the rationale behind this. * export sample-editor results as an audiofile That would be very convenient. * quick create new instrument button. this will simple create an new h2 instrument which include the resulting sample. my idea is, simple arrange the new instrument directly below the instrument that you currently modifying. the problem here is that you have to store the resulting audio file. currently i have no idea where i store this files. That would be even more convenient. But if I have the first option above then I can easily create the new instrument myself. Anyway, an obvious default for the filenames would be ~/.hydrogen/data/samples/%s-%d.%s, where %s.%s is the basename of the original sample, and %d is some serial number to make the filename unique so that you don't overwrite any existing files. but this improvements cannot reconstruct the main goal from the sample editor rubberband implementation. i mean the instrument-layer-rubberband-batch-processor-function. :) Yes, that's a very nice feature. But DrMr could support this in the future as well, as soon as hosts adopt the LV2 Time extension which is still in the making. So I'm not sure that I buy your argument that the two are for totally different use cases. :) What's special about Hydrogen, however, is its user interface. People like it exactly because it's so dead-easy to use for the purpose that it has been designed for. And now we can use Hydrogen to create the drumkits and patterns that we need, and then employ DrMr to port them over to Qtractor where the rest of the arrangement can be done. That's very useful already, even though DrMr has only been announced less than a week ago. ;-) DrMr definitely fills a gap there. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/01/2012 07:40 PM, Rui Nuno Capela wrote: So here it goes: Ardour is a full fledged, pro-level DAW and, for crying out loud on its own, the flagship of the free/open-source pro-audio fleet and movement, not only Linux anymore nowadays. It goes without saying that Ardour offers an abundance of features, but Qtractor's MIDI support is very good, its audio support is more than just adequate, and its big plus is that it's so easy to learn and use. Also, despite the "alpha" sticker that you keep putting on it, it's been working very well for me. In any case, we can be happy that we have both. :) Now what's still needed is full-fledged OSC support. I mean not just automation, but real OSC tracks with full recording, playback and editing capabilities a la MIDI. We've briefly discussed this on the Qtractor mailing list, and I think that I've read somewhere that Ardour3 has been designed with that in mind as well. But are there any concrete plans to add an OSC track type to Ardour? That would be a killer feature, at least for me. * Panic command button (NEW) Can you read my mind? :) I was about to ask for this, and now you've already implemented it! Nice. One thing I've been wondering about... Could you please elaborate on what exactly the --enable-lv2-state-files configure option is for? That was marked as experimental in previous svn revisions, and is one of the very few options which are disabled by default. Rui, thanks for all your hard work, and see you @ CCRMA! Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/02/2012 07:17 PM, Rui Nuno Capela wrote: it is disabled like so because current implementation is fubar on qtractor Ok, so I'll just leave it disabled. Thanks for clarifying this. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 06:50 AM, David Robillard wrote: There is also the chicken& egg problem, last I checked there wasn't an OSC note standard in use anywhere to have Ardour send... I don't see why an OSC track should make any assumptions about the semantics of OSC messages. It should just treat it as control data and allow to record it from an OSC client (which might also be an LV2 plugin which produces OSC messages), edit it, and play it back to another OSC server (or LV2 plugin which consumes OSC messages). Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 08:25 PM, David Robillard wrote: Sure, you could just implement dumb raw OSC recording and playback, but there's little point in using a DAW for that (not to mention little practical musical use) But that's exactly what I want. For starters, even just simple messages consisting of address and POD (like a double value) would be useful. The data might originally be generated with a multitouch OSC device, say, and would be recorded by the DAW, which would also let me play back the data, sending it either to an OSC-capable plugin or an external OSC application (Pd, say) which would know what to do with it. Call it automation, if you want. But I think of it as sequencing of OSC messages; I need the data to be on its own track where I can edit, cut, copy and move it around as needed. DAW and sequencer programs are good at these things; that's what they are for. And no, I don't want to use MIDI instead, where I have to cram everything into control changes or (N)RPNS and loose both resolution and the descriptive OSC addresses. I don't know if it's of practical use for anyone else, but time and again I would have had good use for this apparently simple feature. If anyone knows a sequencer or DAW which can do what I sketched out above, please do tell me. OSC has been around since 1997, for crying out loud. It's about time that sequencers do more with it than just automatizing the transport controls. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 11:29 PM, Paul Davis wrote: you can't send OSC to "an OSC capable plugin" or "an external OSC application" in any generalized sense, because there is no shared format for the messages. Yes, there is. It's the OSC format itself. If you want to keep it simple, you could boil it down to "atomic" OSC messages (i.e., POD payload, no bundles). If you can support that in a DAW, I'm sure that there will be plenty of applications which can make good use of this. (Actually just simple pairs of OSC addresses and double values would be good enough for a lot of stuff IMHO.) then its about time that people using OSC start defining some standardized messages. Well, what you see as a problem, I see as a virtue. It gives me the flexibility to just pick my own set of messages for the application at hand. The sequencer shouldn't have to care about the particular set of OSC addresses I'm using. MIDI did this from the start, and for all of its limitations, its been a wild success. Nobody argues that, certainly not me. For much stuff we do, MIDI is quite adequate. But there's also the more advanced stuff where OSC is better suited or maybe just more convenient. That's certainly the case if you're using an OSC device like the Lemur, or if you're building a dsp plugin with Faust and don't want to go through the tedium of handpicking MIDI controller assignments. Anyway, Paul, I understand that you have plenty of other important stuff on your TODO list for Ardour3. I'm not complaining. The reason that I brought up Ardour in this context was that I seem to recall reading something on the Ardour website, about Ardour3 already having the right infrastructure which would make it easy to add some kind of OSC tracks. Maybe I've misread that remark, though. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/03/2012 11:36 PM, Robin Gareus wrote: I use Algoscore for sequencing OSC. http://kymatica.com/Software/AlgoScore Hi Robin, thanks for the pointers. Yes I know about AlgoScore and Iannix, but that's not quite what I had in mind. There was a presentation at Piksel a few years back about this one: https://github.com/sentinelweb/TimeLine-OSC Interesting, I don't remember seeing this. Unfortunately, the original website is down and the video on vimeo has lousy sound, but I'll have to see whether I can get this up and running. ..but neither aims for, or comes close to "DAW" functionality. Alas. Maybe I'm a bit old-fashioned, but for recording and playing back stuff on a timeline, nothing beats a DAW-like interface for me. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/04/2012 03:31 AM, David Robillard wrote: However, I doubt Ardour ever will, nor do I think it even should, support sequencing of events that are transmitted by some mechanism other than Jack. That would be a gigantic inconsistent mess for more reasons than I feel like listing, and trying to use UDP or whatever directly in a DAW raises a very large number of very deep questions for no benefit (hell, anti-benefit, Jack rules). Integration with IP based OSC transport should happen via a separate Jack program. That makes perfect sense to me. As Paul pointed out in his response, the reason for this lack is that OSC simply doesn't do what 99.% of the people who use a sequencer want to do. 99.% of the world population is zero, I guess that's me, thanks. ;-) That's your take on what users want, I disagree. Add OSC tracks to Ardour and people will find good uses for it, that's my take. Blindly recording events with no editing or display ability simply isn't that useful, and certainly doesn't constitute a MIDI replacement. Why should it be recorded blindly? It's not rocket science to come up with a convenient interface to edit and visually represent something like generic OSC data. In fact, Ardour automation would almost fit the bill if there was a way to record and play the data from/to external devices and applications in a way which doesn't take the MIDI detour. You can argue that OSC is too limited all day, but in any case it's better than 7 bit values with 7 bit addresses. I'd be more than happy to use any other semi-standard format which offers this and has at least some support in applications. But what we have right now for transferring control data is MIDI and OSC. If you know about anything else please do tell me. I can't drive a Pd patch with a data format that doesn't exist. I can get control data from OSC devices and feed that to Pd, however. Just bad luck that none of the major DAWs supports it directly, so I have to fit my square OSC peg into the round MIDI hole to make that work. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/04/2012 03:47 AM, David Robillard wrote: I probably said this. Internally it's like Jack in most of the important places, i.e. the actual type of the event payload is pretty much irrelevant. The biggest problem to solve is the on-disk format. That shouldn't be a real problem. OSC is already serialized after all, and uses network byte order. So you can just take those blobs and save them to a file and read them back again. Control data (i.e. "automation") in Ardour is its own thing, not even really MIDI related. I co-opted the existing automation system as much as possible deliberately for this reason. It could be made to *send* OSC messages for curves pretty easily. If it can be made to also record OSC messages and if I can pick the OSC addresses that I want, then this would probably satisfy most of my needs. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/04/2012 06:32 PM, David Robillard wrote: What do you mean by "pick the OSC addresses that I want"? I mean those symbols with the slashes that are the first part of any atomic OSC message like /foo/bar 4711.0. Usually such a symbol would denote the particular control that the value applies to. When using OSC as input to or output from automation, obviously I'd have to specify which OSC addresses I want to be mapped to which automation parameter. However, I'd actually prefer a kind of separate OSC track which would be connected to OSC inputs and outputs and listens for all OSC messages on its OSC inputs, no matter what the addresses are. So (an ASCII representation of) the contents of such a track might look like # delta OSC addr value 0 /foo/bar 0.78 10 /reverb1/wet 0.3 5 /foo/bar 0.66 etc. etc. By these means the OSC track would just record any messages that it receives on its inputs, and I might then map them to the appropriate automation parameters on other (audio and MIDI) tracks in the DAW, or just have them played back via the OSC outputs assigned to the track, in order to drive some other application like Pd. Dave, will you be at LAC in April? I'd really like to discuss this in more detail with you, but it's much easier to do this in a room together and with a whiteboard and a data projector within reach. ;-) If there's enough interest, maybe we could do a "control beyond midi" brainstorming session at LAC? Maybe Rui wants to join us there, and I know that some guys at CCRMA are also interested in this. I guess that the organizers can allocate us a time slot and a room with the necessary equipment if we just ask for it. Albert P.S.: Rui, apologies for hitchhiking your thread. I hope that you will forgive me over a glass of good Californian wine. ;-) -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OSC sequencer idea (was: Qtractor 0.5.4 - Echo Victor shouts out!)
On 03/04/2012 10:44 PM, Stephen Sinclair wrote: It seems this debate is how to represent OSC messages in a sequencer. Hi Stephen, thanks for chiming in, so far I felt a bit like a lone voice in the wilderness. :) It's nice to see that there are others who see the need for this and are actually working on related software. Thanks also for the link to the MappingTools project, this looks very interesting. I'll have to give this a whirl asap, it looks like it will be very useful for some things I'm working on. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!
On 03/04/2012 11:26 PM, Rui Nuno Capela wrote: no worries. given the length of the thread i think i'll take two please ;) Ok, granted. I'd even make that two bottles if you implement OSC tracks in Qtractor. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
