--- On Mon, 10/19/09, David Henningsson <launchpad....@epost.diwic.se> wrote:
> > First - thanks for helping out with the much needed > testing! > Actually thanks to all those who have contributed to the project. > Out of curiosity, you mentioned aplaymidi before. Do you > play the song via aplaymidi and alsa-seq drivers, or do you > supply the midi file to fluidsynth on the command line? Short answer: for this test, I use aplaymidi to send midi events via alsa-seq to fluidsynth, which sends audio to jackd to the hardware driver. Later I can look into having audio effect plugins (i.e. jack-rack), have tried it, but don't use sound effects much yet. Round-about answer, it depends on what I feature(s) want to use. I'm just trying different things with different apps. I used to use Kmid, but no one ported it to Qt4/Kde4 yet, not sure how long before it would be called an orphan. If I find time to practice playing the midi keyboard, I would like to play (practice) along with some midi file(s). With a separate app, I can use it to send the midi event to "virtual midi port" and not having to worry about the various midi-port number/name changes. Patchage, or various other conneciton saving apps haven't wow'ed me yet. Sometimes I want to pick up a sequence of fast notes, for keyboard or guitar practice, tempo control allows me to slow things down. I want to be able to eventually play live on a midi keyboard, having the PC/laptop as a decent sound module and arranger keyboard functions (live rhythm machine with chord change cappability for accompaniments, with maybe a couple of separate PC-keyboards for the arranger function controls). Most of the hardware arranger keyboards and rhythms machines have very limited user interface, to me at least. Generally for computer stuff, I prefer the Unix approach of using the best tool for each task rather than a monolithic app, only run the tasks I need and each of those can be changed or switched out for something better without too much difficulties. Most of the time monolithic apps are resource hogs and slow, it would be worse if you don't like some part of it. Users don't use all the feautures all the time anyway. I cringe everytime I bring up RoseGarden, especially on some older laptops, or even older desktops. For midi's with lyrics, I like Kmid's ability to display midi text/lyrics, tempo change, transpose, keyboard note display. Timidity lyrics display sucks, only one interface allows decent control for skiping forward/backward, tempo change, transpose, while note display maybe just in win32... PyKaraoke is good at lyrics display but doesn't have any other controls I want from time to time like tempo change, transpose... Rosegarden doesn't show lyrics, it does display notes for each midi channel in realtime pretty well. It allows lasso-select from the mouse to play the selected notes as each note (or a bunch of notes) got selected. Also use Timidity from time to time, it used to have an annoying "clicking" problem with some soundfonts, which has been fixed in recent code change (last few months to a year I think). It was about some release parameters, or looping ability of the sample, if I remember that right. It may be nice to have all of those feature(s) in one huge app, but then the UI might suffer, or I may not like how it may be presented, or the logical flow sequence... Also, for large apps like Rosegarden, or even Fluidsynth, it is a pitty task to try to revamp, refactor, or add new functions. No pun intended, just a fact of life. > > As I type this, I use the mouse to drag the scroll bar > in a GUI text editor, with the midi song playing in the > background, I definitely hear the jitters during the mouse > drag. Not surprising, just mention it here anyway. > > Are XRUNs reported from Jackd? In that case, it is probably > not FluidSynth's fault. Is jackd and fluidsynth running > under rtprio? You are right. XRUNs got in the way, causing jitters/noise. > > Unison.sf2 seems to give the least noise/jitters for > me. It is also the smaller soundfont compare to the > ones listed below. > > Interesting. I've heard that before, that smaller > soundfonts are less CPU intensive, my only theory is that > this has to do with the CPU cache, with more samples, > there'll be more cache misses. This seems a little bit > far-fetched though (not only for the CPU, ha ha). Would be > interesting to know if prefetch instructions could improve > the situation. It is much more detectable on slower hardware like older PCs or laptops -- combination of slower RAM, CPU, HDD... often with less RAM, too. Jimmy _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev