Menu
▾
▴
linuxsampler-devel
|
From: Rui N. C. <rn...@rn...> - 2004-10-02 09:50:02
Attachments:
configure.out
make.out
|
Hi, I just deciced to upgrade my laptop to Mandrake 10.1 (coming from 10.0) and when all the dust settled down (or so I thought) I headed to build linuxsampler from CVS HEAD. Strange enough, I get plenty of compiler errors, something that I suspect is due to gcc 3.4.1, which I'm dealing for the first time. The outputs of ./configure && make are sent on attachment (configure.out and make.out, respectively). This seems to be slightly related to some C++ template issue, as linuxsampler makes massive use of those. I didn't investigated any further. Probably is something about this distro being still very shaky. However, notice that all my Qt projects, which are old-school C++ as you might know, build perfectly fine under this gcc 3.4.1 environment. So I thought someone had already com accross into this or any similiar, and suggest some silver-bullet solution? Has anyone the kindness here? Thanks, -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Steve H. <S.W...@ec...> - 2004-10-02 10:26:38
|
On Sat, Oct 02, 2004 at 10:48:01AM +0100, Rui Nuno Capela wrote: > Strange enough, I get plenty of compiler errors, something that I suspect > is due to gcc 3.4.1, which I'm dealing for the first time. Yes, 3.4 follows the C++ (and C for that matter) rules much more strictly this causes some programs to fail building. - Steve |
|
From: Christian S. <sch...@so...> - 2004-10-02 21:33:06
|
Es geschah am Samstag 02 Oktober 2004 12:26 als Steve Harris schrieb: > On Sat, Oct 02, 2004 at 10:48:01AM +0100, Rui Nuno Capela wrote: > > Strange enough, I get plenty of compiler errors, something that I suspect > > is due to gcc 3.4.1, which I'm dealing for the first time. > > Yes, 3.4 follows the C++ (and C for that matter) rules much more strictly > this causes some programs to fail building. Is 3.4 only more strictly or are there also some known incompatibilities backwards? I just wonder if we should go with 3.4 now or wait until the 1st release. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2004-10-06 13:31:42
Attachments:
linuxsampler-0.2-gcc-3.4.1.patch.gz
|
Hi, Christian Schoenebeck wrote: > Steve Harris wrote: >> Rui Nuno Capela wrote: >> > Strange enough, I get plenty of compiler errors, something that I >> > suspect is due to gcc 3.4.1, which I'm dealing for the first time. >> >> Yes, 3.4 follows the C++ (and C for that matter) rules much more >> strictly this causes some programs to fail building. > > Is 3.4 only more strictly or are there also some known incompatibilities > backwards? I just wonder if we should go with 3.4 now or wait until the > 1st release. > OK. I think there's no need for such dramatic measures ;) The attached patch solves all reported compilation problems, at least on my gcc-3.4.1 platform (Mdk 10.1c). It builds and runs as usual now. The major incompabilities came from Bennos's RTELMemoryPool.h, which I had to spend some time to change and comply, with minimal impact. IMO the incompabilities exposed by the original doesn't make any sense at all, as it looked like quite legal C++ code, as in fact was before gcc-3.4 coming to town. Please, I'll beg you all review the changes and check if there's any issue lurking around. If nothing gets wrong in between I may commit to CVS ASAP. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <sch...@so...> - 2004-10-06 21:30:14
|
Es geschah am Mittwoch 6. Oktober 2004 15:27 als Rui Nuno Capela schrieb: > > Is 3.4 only more strictly or are there also some known incompatibilities > > backwards? I just wonder if we should go with 3.4 now or wait until the > > 1st release. > > OK. I think there's no need for such dramatic measures ;) > > The attached patch solves all reported compilation problems, at least on > my gcc-3.4.1 platform (Mdk 10.1c). It builds and runs as usual now. > > The major incompabilities came from Bennos's RTELMemoryPool.h, which I had > to spend some time to change and comply, with minimal impact. IMO the Mmm... sorry to say, but in my current dev version RTELMemoryPool.h is already dropped. I replaced it by complete new Pool classes. So... > Please, I'll beg you all review the changes and check if there's any issue > lurking around. If nothing gets wrong in between I may commit to CVS ASAP. I don't have gcc 3.4 but I'm surprised about some things, e.g. why gcc 3.4 insists on some of these "this->" pointers and e.g. the #include <errno.h> in rtelmemory.h. But the patch is ok, of course. I'm not yet sure when I'll commit my stuff, cause I'm still fighting with some problems, so please go ahead and commit it. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2004-10-07 16:23:25
|
Hi Christian, > > I don't have gcc 3.4 but I'm surprised about some things, > e.g. why gcc 3.4 insists on some of these "this->" pointers and > e.g. the #include <errno.h> in rtelmemory.h. > Beats me :) I'm also puzzled with th "this->" issue too. The compiler just kept complaining that those inherited protected variables weren't being declared. The included "errno.h"s were needed, most probably because it isn't being implicity included anymore by some other header file. gcc-3.4 include file structure has perhaps changed, but not sure. > But the patch is ok, of course. I'm not yet sure when I'll commit my stuff, cause I'm still fighting with some problems, so please go ahead and commit it. > OK. I'll apply it tonight. On another subject, I noticed that linuxsampler maps MIDI channels number in a off-by-one difference to ALSA sequencer numbering, which equals the native low MIDI command address level. I think the following table shows this mismatch: MIDI MIDI channel channel address number linuxsampler alsa-seq ------- ------- ------------ -------- 0 1 All channels 0 1 2 1 1 2 3 2 2 ... ... ... ... 15 16 15 15 That is, 0 (zero) means "All channels" to linuxsampler(MidiInputPort::midi_chan_all), but for ALSA and low-level MIDI for this matter, it's the valid MIDI channel address 0 (zero), or MIDI Channel 1 (one). Moreover, the "All channels" linuxsampler specification doesn't seem to work at all, being just single mapped to MIDI Channel 1 (address 0). So I would ask, what's the status for this "All channels" (omni?) mode? It doesn't seem to be implemented in MidiInputPort, where I think it should be. Additionally, I think this MIDI channel numbering should be explicitly, if not, better documented. For example, the LSCP command SET CHANNEL MIDI_INPUT_CHANNEL assumes MIDI channels being given in the range 1-16. Or so I think (the RFC document is not explicit on that). However, the "ALL" channels" mode is clearly mentioned. Any comments? -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <sch...@so...> - 2004-10-09 01:17:38
|
Am Donnerstag, 7. Oktober 2004 18:21 schrieb Rui Nuno Capela: > stuff, cause I'm still fighting with some problems, so please go ahead and > commit it. > > > OK. I'll apply it tonight. I also made the transition to gcc 3.4 tonight. Hope latest version still compiles for gccs < 3.4. > On another subject, I noticed that linuxsampler maps MIDI channels number > in a off-by-one difference to ALSA sequencer numbering, which equals the > native low MIDI command address level. I think the following table shows > this mismatch: > > MIDI MIDI > channel channel > address number linuxsampler alsa-seq > ------- ------- ------------ -------- > 0 1 All channels 0 > 1 2 1 1 > 2 3 2 2 > ... ... ... ... > 15 16 15 15 I first tended to say no, this is fine, because the majority of musicians is used to the 1..16 indexing of MIDI channels, but then I remembered that everyhting else in LS is indexed starting by 0 (sampler channel, audio channel, etc.). So to avoid having an exceptional case here, I now changed MIDI channel indexing globally to the low level variant 0..15, too. > Moreover, the "All channels" linuxsampler specification doesn't seem to > work at all, being just single mapped to MIDI Channel 1 (address 0). Yep, fixed now in latest CVS: > be. Additionally, I think this MIDI channel numbering should be > explicitly, if not, better documented. I agree this should be mentioned in the documentation. Would you like to add it to the LSCP RFC or should I do it? Again, MIDI indexing is now 0..15 and 16 would be "list to all MIDI channels", but on LSCP level the keyword "ALL" should be used instead of 16; I tend towards adding a WRN result, if somebody tries to use 16. CU Christian |
Thanks for helping keep SourceForge clean.
X