On Sun, Apr 11, 2010 at 6:12 PM, Orcan Ogetbil <oget.fedora(a)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 (
http://old.nabble.com/using-qmidiroute-for-midi-device-control....-ts2796...
).
So at some point that may motivate me to compile
http://sourceforge.net/projects/alsamodular/files/QMidiRoute/0.3.0/NEWS.t...
and
maybe package it. Some of the work has already been done for F10:
http://sourceforge.net/projects/alsamodular/files/QMidiRoute/0.3.0/qmidir...
http://sourceforge.net/projects/alsamodular/files/QMidiRoute/0.3.0/qmidir...
Finally, and longer term, I'd like to see QMidiCtl and QMidiNet added to
fedora:
http://old.nabble.com/QMidiCtl-and-QMidiNet-(was-Re:--Pd-%2B-PulseAudio-)...
;
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
http://old.nabble.com/help-getting-netjack-MIDI-working--(looks-like-it...
)
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:
(2) Alternately&&more complicated, if using netjack, must also bridge midi
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
instead.
<
http://old.nabble.com/help-getting-netjack-MIDI-working--(looks-like-it...
--
Niels
http://nielsmayer.com