Hello dear all LAUers.
Time ago I did some research about open source/free software licences:
types, pros and cons, etc. I'm reviewing it and, given that I follow
and love many of the great projects and applications coded by members
of this list, I would love to here you're opinions (pros, cons) and
experience in practice and why you chose X licence for your project(s)
(business model or enterprise view in mind, 'cause you like it...).
I see that the most commons are GPL2 (some don't like yet the v3) and
GPL3. And nowadays with so many services in the cloud also AGPL, and
Thanks as always for sharing your work and knowledge.
* Musix GNU+Linux
For what it's worth, I did finally discover why Simple Sysexer,
JSynthLib, and just about every other method I've tried (including even
hardware, such as the MDR sysex recorder built into the Yamaha SY99)
were unable to transmit my patch bank to the Siel DK600, but the Linux
'amidi' command could: It's made up of alternating Midi CC's and sysex
dumps in the same file, about 90 of them ("CC...sysex...CC...sysex...").
Apparently, since the Siel DK600 cannot receive whole patch banks and it
needs to be prepared to receive just one patch with a Midi CC command,
if you want to dump all 90 patches, you need a file that contains just
such a weird chain of CC's and single patch dumps. It comes to only
about 4kB, but such a file confuses just about any higher level utility,
or at the very least makes them skip the necessary CC's and just send
the sysexes. Amidi is raw enough that it doesn't care what it's
transmitting, so it just works.
But that brings me back to amidi's wanting to try to just grab the Midi
device, which makes it not work when Jack is running. So what I need is
a Jack-aware app (or at least an Alsa Midi app that doesn't grab the
device exclusively) that's smart enough to work with Jack but still dumb
enough to not care if what it's transmitting.
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
Just released a debut release by a band I'm in last weekend, which I just
realised is pretty much a linux project. Everything was recorded straight
to harddrive through an analog mixer. So not an analog studio, but a
computerless studio anyway.
Drums recorded live with the rest of the instruments playing along in the
room, so a lot of guitars and bass on the drum tracks, so was quite a
challenge massaging the drums into sounding like drums without interfering
with the guitars (which we recorded on top of the drums afterwards the same
day). Everything recorded in two evenings a cold weekend earlier this year.
Mixed and fixed in ardour 2 this spring/summer (can't quite remember). Not
super happy with the sound, but it was a mess before the mixing process, so
quite satisfied after all.
Hope you enjoy!
Hello all Users & Devs of linux-audio-land,
Moving forward from the topic on Aeolus and forking projects, perhaps it is
wise to look at how the community as a whole can grow from this situation:
1) It seems the frustration of forks is mainly due to lack of communication.
2) Had appropriate communication been in place, patches could have been
3) If 1) and 2), then the community flourishes as a whole.
In the Aeolus thread on LAD, Michel Dominique wrote (and I feel its
"That imply we must communicate more with each other"
"I think this is a big problem, and not only related to Fons work, or the
LAD, but to the whole community."
The mailing list you're reading from now is one of the central hubs for the
The -developers list is the perfect place to announce projects, forks,
The -users list is good for asking users and interested parties questions.
I will try to announce more patches / code, to contribute upstream, and
hopefully benefit the community.
I'm thinking about mixing down some old stuff, dredging out some old ideas and finishing them up.
Alas, though, my old studio laptop is gone (it's been my daughter's for years now, and has long since been wiped).
I have a great new i7 laptop, but I've got it set up for Work Stuff and I'm not changing that. Nor do I want to reboot it to do music stuff; I'd only do that for only an hour here and there rarely, and wouldn't want to lose my environment (read: emacs session, mosh sessions, and Firefox/Chrome tabs) and bring it all back.
What I'd really like is to run something like AVLinux inside KVM, with just enough resources to run Ardour and some plugins and maybe low-resource synths. I can book AVLinux just fine, but the problem I've had is that I cannot for the life of me get audio working. I get errors from KVM.
Has anyone successfully gotten audio to work from inside of a KVM VM? Is there any special magick I need to do to get this happening?
Also, I understand that if I'm not running a RT kernel on the host machine, I won't get RT performance on the VM's, but I don't think I need that for mixing. Are there any reasons why running say an Ingo kernel inside a KVM box wouldn't work?
lately, I have seen many projects showing linux (or android) onboard on
some small box including processor and some audio inputs/outputs..
Okay, but does anybody know about such box that would include MIDI input?
I use VL-70m synthesizer which is quite bigger (and expensive, well..) - so
I was thinking to get such box and use it for street performances as small
midi synthesizer.. I have Raspberry Pi at home, so I can try to use some
midi->usb but I was thinking that maybe there is some specialized solution
that already works? I didn't find anything yet :-/