Hi,
Just noticed about this recent release of JUCE 1.10:
(http://www.rawmaterialsoftware.com/juce/)
which I think is the first one ready for build on Linux. Indeed, I've just
tested the "jucedemo" program and it seems to be running quite fine.
Impressive, I may say.
As expected, only the GUI code is now working, and I almost sure it is
working pretty well, at least on my X.org boxes. I'm quite excited to know
that JUCE Linux native port has evolved and is materializing.
However, the Audio and MIDI abstraction framework is still to be filled in.
And this is exactly the purpose of this very post--yet again, if you
remember, since last January exchange on this :)
You might remember then, that I've brought this very subject into
attention to the Linux Audio Developers and USers (LAD/LAU) mailing list,
and to put a long story short: help is being here reiterated to write the
native Linux Audio and MIDI implementations of the JUCE C++ framework,
which among other things, may bring a native Tracktion Linux port into
light :P
Given that JUCE is being released under the GPL, and if some of the LADs are
willing to help (me included), things just could happen sooner than later ;)
That said, I'm all about taking explicit directions for a JACK
implementation on JUCE's Audio interface, and ALSA-sequencer for MIDI. Is
there something already in the works or is it something that some of us
(the LADs) can step in and give a hand ?
And what about public hosting of the JUCE project, given that its being
released under an open-source license (GPL)? Yet again, this is just a
humble suggestion of mine. To give you an hint, sourceforge.net's project
name "juce" is still available for registration, or so I believe.
I'll be very happy to know about some comments on this. Specially from the
LADs. Thanks anyway.
Cheers.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
>Hi Majik,
>
>majik wrote:
>
>>---Here is an email I sent a little while ago to Kai Vehmanen:
>>
>>
>>
>>> I have been looking through the Soundtracker 0.6.7 code as I have
>>> been
>>>wanting to improve the jack output. It would be excellent if Soundtracker
>>>could output each of its channels to a Jack port, instead of (as well as?)
>>>outputting the mix the two mono channels. Unfortunately, Im only a beginner
>>>when it comes to audio coding and was wondering if someone could hack it
>>>together for me?
>>>
>>>
>>
>>
>>---And his reponse:
>>
>>that would be a cool feature to have, but unfortunately not a trivial
>>thing to add (though not impossible either). You could try to ask about
>>this on the soundtracker mailing list (or possible on linux-audio-dev)...
>>maybe someone else is also interested and has the time to help.
>>Unfortunately I don't have much time for FOSS-development atm, so I'll
>>have to pass. .(
>>
>>
>>---Will anyone help with this? I believe that the problem is that the mixer
>>code works in a monolithic way, thus needs a rewrite.
>>
>>
>>
>This issue's been discussed on the soundtracker mailing list, months ago.
>
>Here's a quote from Yury Aliaev, a Soundtracker contributor :
>
><quote>
>In the current state of ST such a thing (multichannel output) is almost
>impossible because of the monolitic structure of the mixer code. The
>optimal way to solve this is (I mean) rewriting the whole mixer in the
>modular way. This also will make ST more flexible and universal and, in
>particular, will make adding new effects (including LADSPA processing)
>more easy.
>
>Currently I have some ideas how to do this (but still have no free time
>for this :( ), but there is another way: libremix written by Conrad
>Parker (see remix.sf.net) seems to be good for this purpose.
></quote>
>
>
>A question I asked, a few weeks later :
>
><quote>
>
>> About per track JACK outputs : In your answer to Emiliano Grilli, on
>> june 1st, you explain that this needs a big rewrite. But do you
>> believe a sort of hack is possible ? Like a small patch that lies
>> around for those (I like JACK :) who need this feature before
>> soundtracker engine gets rewritten... If yes, any advise ? Does it
>> imply playing with the mixer assembly routines ?
>
></quote>
>
>And Yury's answer :
>
><quote>
>Unfortunately, it will be a havy hack of assembler routines :( Because
>they mix sounds from different channels directly after resampling,
>rather then write to the separate buffers and then mix them. This is why
>I decided to rewrite the mixer entirely rather then inventing kludges...
></quote>
>
>
>Hope it helps... Yury may have started to rewrite the mixer.
>
>Regards
>
>--
> og
Yes, I did see this, I just wanted to re-illuminate the topic and appeal
through LAD to see if anyone did have some free time to develop this, as I
feel it would be such a great feature.
Matthew Carey
Dear sir,
The HTPC market is growing and Linux has a strong presence here via
software offerings like MythTV (http://www.mythtv.org/). A significant
portion of HTPC users are interested in quality audio such as the one
offered by professionnal sound cards.
Simultaneously there is a drive to make kill all sources of low latency in
the Linux kernel (http://lwn.net/Articles/120797/) to accomodate
professionnal audio needs. Large professionnal Linux audio communities
already exist (http://jackit.sourceforge.net/,
http://www.linuxdj.com/audio/lad/) and the level of interest is high
enough to be seen by some as driving the next major release of the Linux
kernel
(http://www.computerworld.com.au/index.php/id;669959914;fp;16;fpid;0 last
§)
Current Linux sound card support is good for mass-market products and
high-end (RME, M-audio...) ones but no one has filled the intermediate
audiophile/semi-pro/home-studio niche yet. The E-MU 1212m
http://www.emu.com/products/product.asp?maincategory=754&category=754&produ…
would seem to be ideally positionned to respond to this demand on the
hardware side, except it has no Linux driver support right now. The Alsa
project (http://www.alsa-project.org/) however has expressed interest on
working on the problem provided they get an hardware sample.
Since Alsa already develops drivers for other Creative sound cards with
Creative support cooperating it would seem natural to expand the current
partnership to the E-MU sound card family. I hope I made the case for such
a partneship clear (I'm no native english speaker) and I'll soon be a
happy Linux E-MU customer.
Kind regards,
--
Nicolas Mailhot
Hi,
we're currently four people for the linux audio booth. This is
still too less because each of us wants to have some leisure
time to visit other projects and talks. I think that six
people is great, so at least three of them can always be at
the booth. Even if you do not plan to be at Linuxtag over all
the days your help is really welcome.
So we're still looking for people who want to join us,
mainly being at the booth, answering questions and demoing
software.
Information about the Linuxtag can be found on
http://www.linuxtag.org/2005/en/home.html
If you're interested, please contact me via personal mail.
Thanks & best regards
ce
---Here is an email I sent a little while ago to Kai Vehmanen:
> I have been looking through the Soundtracker 0.6.7 code as I have been
> wanting to improve the jack output. It would be excellent if Soundtracker
> could output each of its channels to a Jack port, instead of (as well as?)
> outputting the mix the two mono channels. Unfortunately, Im only a beginner
> when it comes to audio coding and was wondering if someone could hack it
> together for me?
---And his reponse:
that would be a cool feature to have, but unfortunately not a trivial
thing to add (though not impossible either). You could try to ask about
this on the soundtracker mailing list (or possible on linux-audio-dev)...
maybe someone else is also interested and has the time to help.
Unfortunately I don't have much time for FOSS-development atm, so I'll
have to pass. .(
---Will anyone help with this? I believe that the problem is that the mixer
code works in a monolithic way, thus needs a rewrite.
>From: Andy Wingo <wingo(a)pobox.com>
>
>socketpair(2) will do, either polling or reading in the low priority
>thread will sleep until the high priority thread writes a byte.
I hope we get all the possible methods listed now.
I have used signals for years in my alsashmrec. One process
reads A/D to a ring buffer and another process empties the ring
buffer to the disk. The problem was how to make the disk
process (non-RT process) to wait.
When the disk process has no data in the ring buffer, it goes to
sleep:
kill((pid_t)diskpid,SIGSTOP);
When the A/D process has written enough data to the ring buffer,
it wakes up the disk process:
kill((pid_t)diskpid,SIGCONT);
Because A/D process uses smaller buffer size, the A/D process
is executed multiple times before SIGCONT is sent.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
The ZKM/DEGEM internet radio station (which hosted the LAC2005 concert
streams) wants to produce a special on the conference. To fill this
program with interesting music, I would ask all composers and musicians
on this list to send me either links where a selected piece can be
downloaded or directly mail an ogg or mp3-file. Please use the following
address directly (so not to spam this list): audio(a)uni-lueneburg.de
The ZKM/DEGEM internet radio will be launched at the "next generation"
conference to be held at ZKM in June. The LAC2005 special will be on the
program right away and will be streamed on a daily basis for one entire
month. Both ZKM and DEGEM (German Society for Electroacoustic Music) are
nonprofit organizations and submitted music will only be used for this
single radio program. A link to the internet radio stream will be posted
on this list as it becomes available.
Thanks to everybody for cooperation, Florian Grote
KMidimon 0.1
============
KMidimon is a MIDI monitor for Linux using ALSA sequencer, with KDE user
interface.
Quoting Dave Phillips in a three parts article for Linux Journal: "At some
point, almost every serious MIDI musician needs to monitor a MIDI data stream,
perhaps to diagnose a malfunctioning piece of equipment or to examine the
contents of a MIDI sequence during playback".
Features:
* Easy to use KDE graphic user interface
* Based on ALSA sequencer
Provides one input port to be connected to other programs and devices
using the usual external tools (aconnect, kaconnect, QJackCtl...)
* Customizable event filters and sequencer parameters
* Supports all MIDI messages, including System Exclusive, and ALSA messages
* Saves to a text file (CSV format) the recorded event list
* GPL licensed
Provisional home page:
http://kmetronome.sourceforge.net/kmidimon/
Download:
http://prdownloads.sourceforge.net/kmetronome/kmidimon-0.1.tar.gz?download
KMetronome 0.5
==============
KMetronome is a MIDI based metronome using the ALSA sequencer.
This is a maintenance release fixing some compilation and runtime bugs.
Please upgrade.
Home page:
http://kmetronome.sourceforge.net/
Download:
http://prdownloads.sourceforge.net/kmetronome/kmetronome-0.5.tar.gz?download
Changes
-------
release 0.5
* autosave window settings (size...)
* apply tempo/resolution when accept changes in configuration dialog
* fixed bug in sequencerthread: set_program event must be direct.
* other minor changes
release 0.4
added features
* Internal connection management now remembers the input port connection.
* new setTempo and setTimeSignature functions added to the DCOP interface.
fixed bugs
* fixed compilation problem under Fedora Core 3
* fixed some automake problems
I've been puzzling over something that I thought
someone on this list
might have a good solution for. I need to make a low
priority
(non-real time) thread wait for a real time thread to
do something. I
can't use a semaphore or condition variable for this,
because that
would mean the low priority thread must briefly take a
lock while
examining the condition variable or sempahore. If it
were to be
pre-empted while holding this lock, the RT thread
could block waiting
to obtain the lock in order to signal the condition or
modify the
semaphore.
I could prevent this by raising the priority of the
low priority
thread before taking the lock, but I don't know how to
do this in
a portable way (i.e., I want my app to port to windows
and mac, but
even on "posix compliant" systems, getting RT
privileges seems to
be pretty system-dependent).
It occurs to me that I could just "busy wait" using a
timer, which
would work but is a bit inelegant. Has anyone else
come up with a good
solution for this problem?
Thanks for any thoughts -- Ken McMillan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi!
I downloaded a couple of recordings from
http://www.linuxdj.com/audio/lad/contrib/zkm_meeting_2005/
The MuSE stream seems to have a big chunk of silence at the end (from
min 28 on).
There seems to be some problem with ardour stream beginning around min 76.
Regards,
Luis