[PlanetCCRMA] [Fedora-music-list] new packages in Fedora updates-testing (2010-04-10)

Niels Mayer nielsmayer at gmail.com
Mon Apr 12 21:49:51 PDT 2010

On Sun, Apr 11, 2010 at 6:12 PM, Orcan Ogetbil <oget.fedora at gmail.com>wrote:
> Great. To join, basically you need to come up with a new package, then
> prove that you understand the Fedora guidelines during your package
> review and get sponsored in Fedora.
> The process is described in detail, with all the relevant links at
> http://fedoraproject.org/wiki/PackageMaintainers/Join
> The rule is, your first package needs to be reviewed by a sponsor.
> Unfortunately, I am not a sponsor, so I can't help with that. (maybe
> it's time for me to apply for sponsorship. oh well...)
> Do you see the difficulty here? Your first package will have to go
> into a pool of 700 packages, and hopefully a sponsor will find it
> interesting for a review. But once that is done, everything will go
> easier. It took me ~2 weeks to get sponsored but I know people for
> whom it took months.

Yipes! Sounds like the open-sourcerers apprentice....

For right now, it probably makes sense for me to continue testing packages
you announce.

At some point I'm going to get fed up having to manually load a file into
qmidiroute-0.2.1-4.fc12.ccrma.x86_64 every time I log-in (
So at some point that may motivate me to compile
maybe package it. Some of the work has already been done for F10:

Finally, and longer term, I'd like to see QMidiCtl and QMidiNet added to
even longer term I'd also like to add another program to the "qmidinet bus"
-- qmidiprolog or qmidilisp or perhaps just a way of getting CommonMusic
integrated w/ qmidinet: some way of allowing "event-driven, rule-based midi
programming" to happen. That could allow for something as simple as
implementing different "curves" on controllers, or as complex as algorithmic
arpeggiators, or even music parsing and live accompaniment. Using the
application partitioning already in place for qmidinet and qmidictl, one
could add a different kind of "controller" that just happens to be rules
firing based on midi input, generating midi output.

> a2jmidi -- i was going to look into it back when i thought i'd be using
> > firewire... didn't bother now that midi. is under control.
> > (Are there any advantages to using a2jmidi and turning off the 'seq'
>  driver
> > in qjackctl/jackd when using the alsa back-end? Other than having the
> same
> > config for audio setups using either alsa or ffado/freebob ...)
> Frankly, I don't know the answer. I packaged it per user request.
> Maybe the actual users will shed us some light.

Here's what I learned previously: (see

summary -- we're missing an ALSA<->JACK bridge on the "slave" side. The
> slave side is sitting there talking to netjack ports not connected or
> bridged to the ALSA devices in any way.

(1) For MIDI only, use:
> http://ccrma.stanford.edu/planetccrma/man/man1/aseqnet.1.html

(2) Alternately&&more complicated, if using netjack, must also bridge midi
> to jack with
> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/12/x86_64/repoview/a2jmidid.html

Unfortunately, planetccrma version is obsolete, version 6 from GIT is
> current/stable version.

(3) Audio also requires an ALSA<->JACK bridging too, like alsa_in and
> alsa_out on the slave-side netjack.

#2 indicates another use/need for a2jmidid -- which is obviated by skipping
the whole netjack mess and using facilities like QMidiCtl and QMidiNet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20100412/fcf5b732/attachment.html 

More information about the PlanetCCRMA mailing list