Hi Flo. I don't think I told you about my follies with freeBSD. One day a few months ago I spent many hours trying to install it with no luck - both my laptops were too old and it didn't like my desktop which has some bad sectors. Thoroughly exhausted, I gave up for the time being.
I really do want to install it and see what's going on. One problem is that it really seems to want to use its own partitioning scheme, meaning I need to find a spare drive... I had a look at the supplied patch. Really weird about that #include "event.h" needing change to #include "../event.h" I don't understand why there's trouble with that one, when the other files like "mpevent.h" have no trouble. I checked it out our build system and there should be no trouble with it. So one thing I thought of was that perhaps "event.h" is actually a system file? Can you recall if any error messages might have indicated such a possibility? I googled "BSD event.h" and only found sys/event.h, and a search here on Linux found two more system "event.h" - one being fluidsynth/event.h and the other lash/event.h, hmmm... ironically both fluidsynth and lash we are using. I wonder if that's (part of) the problem... Thanks for the info about exp10, I didn't know the situation with BSD. Also, one questionable change: In top level cmake file you have 'faked' the detection of ladspa.h. I assume just to get you running... Yeah, I only recently added that detection after I noticed there was none, and it turns out there's no built-in cmake detection and no package-config file for the darn thing! So the only way was direct ladspa.h file detection. Is there anything I can do for you to help that situation? The rtc sections and so on, can be factored-in depending on various configuration flags we will add later. Thanks. Tim. On December 24, 2012 11:23:20 PM you wrote: > bump :) > > -------- Original-Nachricht -------- > Betreff: Re: [Lmuse-developer] please help: what are all the ALSA > dependencies? > Datum: Sat, 22 Dec 2012 14:52:21 +0100 > Von: Florian Jung <[email protected]> > An: [email protected] > > Am 13.12.2012 06:26, schrieb Tim E. Real: > > On December 12, 2012 10:04:06 AM Florian Jung wrote: > >> Hi Tim > >> > >> yeah, i think such an option would be helpful. > >> > >> be aware that FreeBSD offers ALSA headers and the ALSA libraries, you > >> just cannot use any function which wants to talk with the kernel part > >> (i.e., almost every function ;) ) > > > > Ah yes, we'll need either two cmake bool options or one enum option: > > > > Since we are really talking about that DSSI-ALSA compatibility package, > > > > something like either > > > > ENABLE_ALSA_FULL and ENABLE_ALSA_DSSI_COMPAT_ONLY, > > > > or probably better, a single enum option > > > > ENABLE_ALSA {FULL, DSSI_COMPAT_ONLY} > > > > Those are the cmake enable options. Now for the app defines: > > > > If we go with the second idea, we can still split the result > > > > into two separate config defines for the app, like: > > ALSA_FULL_SUPPORT and ALSA_DSSI_COMPAT_ONLY > > > > which the app can check via the generated config.h. > > what's the status :)? could someone please add that. ideally along with > fixing muse not searching libs and includes in /usr/local :)? > > >> But we can compile it, and if libALSA offers some helper functions, i > >> guess we can use them. > > > > I'm thinking, just support DSSI only - that's what the compat package > > > > was intended for, let's not try to hack our way into making MusE > > produce ALSA hardware events and such... > > true, we should not try to "emulate" alsa. but MusE seems to use the > ALSA structures for storing MIDI data. And IMHO, we don't need to change > this; we have the headers, and when dealing with OSS, we can just > translate the stuff into OSS's data structures. > > alternatively and for the long time we could replace all occurrences of > alsa-specific structures by MusE-local structures. So that ONLY the ALSA > driver files actually depend on ALSA. > > >> MIDI access in OSS seems to be very straightforward: you get a devnode > >> where raw midi comes out, or you write raw midi in (i haven't verified > >> that, just a result of quick googling). > > > > So about the driver, wow that's brave but it's a cool idea. Go man! > > What about Jack delivering the midi? > > Ah... I see, you want to capitalize on our discussions about timers > > > > and note resolution :) > > I'd be fine with JACK delivering the MIDI I think, but others might not > be ;) > And from what I've read, OSS MIDI is very simple (as simple as just > write your data to the device, not more), so why not implement it :) > > > Some hi-res timer must be available in BSD. Hard to believe no RTC. > > Maybe it's disguised as something else? In modern Linux I think the > > > > RTC just operates the HPET, the kernel has a RTC_HPET_EMULATE > > or something like that. (And the HPET is accessible via ALSA.) > > > >> Currently, i have roughly done this: > >> - comment out the whole rtctimer file, because there is no #include > >> > >> <linux/rtc.h>. > > > > I guess we'll detect what OS on a per-file level, and allow rtc or not. > > I see no reason to detect OS in cmake /just/ to pass it on to the app. > > (* See below.) > > Uh, why that? What about the following: > - detect the OS cia CMake > - make a fully virtual "interface" class Timer > - make a derived LinuxRTCTimer, LinuxAlsaTimer, FreeBSDWhateverTimer > which implement this interface. > - in main.c, depending on #if LINUX or #if FREEBSD, set the global > variable Timer* our_timer to a new LinuxRTCTimer() or new FreeBSDTimer > > shouldn't that work as well? Or are the timers that different? > > >> - replace all #include "event.h" by "../event.h" > > > > There's 49 usages. Surely at the very least, the ones in the top level > > > > muse2/muse directory are finding event.h ? > > yea that's right. only those files in subdirectories fail to find the > correct event.h. > > > The others may simply be a matter of telling cmake to include the muse > > > > directory from whatever directory the usages happen to be in. > > yes. and possibly a matter of telling it to search there BEFORE anywhere > else. > > i recall that it has actually found an event.h, but a wrong one, OS > supplied. > > can you please fix that, as i have no idea about CMake ;)? > > > Can you tell me any specific usages? Surely not all? > > > >> - add an exp10 macro > > > > What do you mean - if for floats there is exp10f. Both are in <math.h> > > nope, FreeBSD (as a POSIX-conformant OS) has only exp and exp2. > exp10 and exp10f is a nonstandard GNU extension (read man exp10, under > "CONFORMING TO" it says "is a GNU extension" ;) ) > > So i guess we'd just offer a math.h ourselves, like the following: > #include <path/to/real/math/h> > #ifndef exp10 > #define exp10(x) pow(10,(x)) > #endif > > > If for speed well we have fastlog functions in fastlog.h > > But unfortunately no fastexp. > > But these days I just use the math.h versions. > > Mostly for accuracy - lack of it was causing some problems in MusE, > > > > speed is not much of a problem today. > > > >> - manually fix the CMake-generated files so that it links > >> > >> against libs in /usr/local/lib, > > > > Huh? If there is stuff in /usr/local/lib the build system is > > > > supposed to use it instead of the same stuff in /usr/lib. > > > > Sounds like maybe you got ldconfig problems? > > Sometimes one must manually add /usr/local/lib to the > > > > /etc/ld.so.conf file. Sometimes one must manually type > > ldconfig after building and installing some piece of software > > which installs libraries. > > nope, freebsd handles this correctly afaik. > > >> and does not use -ldl > > > > For that we'll probably detect OS in top cmake file, and if > > > > BSD then no -ldl. > > yup. please do that, again, to me CMake is a huge black box full of magic ;) > >> so, i got MusE compiling, but it won't start because of errors like > >> "can't init the midi alsa subsystem!" > > > > Yeah really eh. So close yet so far... > > > > Nuts and bolts: > > ----------------------- > > > > Ok So the fact you want to have a timer and OSS midi changes the > > > > whole ball-game. Completely. > > > > I was aiming for complete removal of the midi thread and all timers. > > This is what Werner's muse_evolution did, pure Jack only. > > (By 'removal' I mean optionally configured out. Not deleted.) > > > > But since you'll have an OSS midi subsystem and timer going, > > > > then this is a matter of KEEPING the midi thread and timer support > > code for your timer. > > wait wait. so you really want to remove nonjack MIDI stuff? i thought > that was always what I wanted and you didn't want ;)? > > > Well anyway, irrelevant. This won't be 'removal' now, just configured > > > > re-implementation. Right? > > No no, if you deem it possible to remove/configure out the MIDI thread > stuff, then go ahead. That would make MusE also portable to systems with > only JACK (and no ALSA and OSS). > > I'd still suggest to continue with removing all that MIDI thread stuff; > that would involve > 1. MusE being Jack-only and > 2. MusE being cleaner, > right? > > > Please continue with your efforts. As I understood this, there will be > still a low-latency ALSA MIDI subsystem, right? Just that we don't > *have* to use/compile it? > That's cool :) > > > Great idea though. Dude, you're gonna rock BSD ! > > yay! :) > > greetings > flo ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
