On Sun, Apr 11, 2010 at 6:12 PM, Orcan Ogetbil <oget.fedora@xxxxxxxxx> 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....-ts27963116.html ). So at some point that may motivate me to compile http://sourceforge.net/projects/alsamodular/files/QMidiRoute/0.3.0/NEWS.txt/view and maybe package it. Some of the work has already been done for F10: http://sourceforge.net/projects/alsamodular/files/QMidiRoute/0.3.0/qmidiroute-0.3.0-1.fc10.src.rpm/download
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-)-ts28030934.html#a28030934 ; 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 usingFrankly, I don't know the answer. I packaged it per user request.
> 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 ...)
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's-working,-just-%09doesn't-send-data)-ts27815119.html#a27817133 )
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 instead.
_______________________________________________ music mailing list music@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/music
