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.
>
> 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...
>
> 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 :)
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.)
> - 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 ?
The others may simply be a matter of telling cmake to include the muse
directory from whatever directory the usages happen to be in.
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>
(What? No math headers either in BSD ? He he.)
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.
> and does not use -ldl
For that we'll probably detect OS in top cmake file, and if
BSD then no -ldl.
>
> 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.
I was going to go into detail about how 'removal' chiefly involves
removing the mid thread, and involves finding replacements for
a few remaining switch cases in MidiSeq::processMsg.
I managed to do several of the cases and move them outta there
already. But the few remaining cases are challenging.
Don't worry about the processSeek and processStop messages, I should
be the one to deal with them as I mentioned before, about all that
commented code in the drivers.
You should know that in my mind, THAT section was practically the
only real barrier remaining to complete 'removal' - the rest of the work
I envisioned as a relative walk in the park so to speak. I hope.
I'm sure if I try more I can break through that section...
Well anyway, irrelevant. This won't be 'removal' now, just configured
re-implementation. Right?
I'll wait till your next reply to go into more detail, maybe my instructions
would go in wrong direction here.
Great idea though. Dude, you're gonna rock BSD !
Tim.
>
> greetings
> flo
>
> Am 12.12.2012 09:53, schrieb Tim E. Real:
> > On December 12, 2012 02:14:32 AM Florian Jung wrote:
> >> Hi folks :)
> >> (yea i'm still alive :) )
> >>
> >> i'm currently trying to get muse working on my freeBSD machine,
> >>
> >> could you please fix the following things?
> >> - search for includes and libs also in /usr/local/{include,lib} (gentoo
> >> users might be affected by this as well
> >> - don't link with -ldl on freebsd, it's included in the libc there
> >> - for some reason, #include "event.h" includes the wrong event.h in
> >> freeBSD; i have to replace it by #include "../event.h"; any ideas for
> >> that one?
> >> - please add some globally accessible macro which tells me whether i'm
> >> compiling on linux, freebsd, fooBSD, or anything else
> >>
> >>
> >> and please explain me in detail, how audio and ALSA stuff is working.
> >> i want to write a new timer (both RTC timer and alsa timer don't work
> >> under freebsd), and a OSS midi subsystem (i don't think i'll bother with
> >> OSS audio, as we have jack.), and i need information about how to do this
> >> :)
> >>
> >>
> >> when you fix the above mentioned things, muse will at least compile
> >> (currently, i edited cmakecaches by hand), but not start because there's
> >> no timer available. (and probably fail beyond that because no midi
> >> driver is available)
> >>
> >> please help me out =)
> >>
> >> greetings
> >> flo
> >
> > Hey Ho Flo! Welcome back.
> >
> > About to shut down here, will answer some more later, but let me say
> >
> > how far have you gotten roughly?
> >
> > What I mean, is the very first thing I can (must) do is add a cmake option
> >
> > ENABLE_ALSA which will lead to an app ALSA_SUPPORT define.
> >
> > I know a few places (and more) that need it but foolishly never got around
> > to>
> > adding an option ALSA_SUPPORT define, so they're just #if 0 and such for
> > now.>>
> >>From there, having the ALSA_SUPPORT define, we can really motor on...
> >>
> > I'll do what I can to start changing the code where I know it needs to be
> > done>
> > but can't promise anything right away - kinda up to my neck in stuff.
> >
> > I'll point out the areas I speak of tomorrow.
> >
> > Tim.
> >
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
