Similar to http://schismtracker.org/scdev/res/1357.html : schismtracker needs -lm because its own fmt/aiff.c uses a symbol from that library. (Issue found in schismtracker-20120105)
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: fmt/aiff.o: undefined reference to symbol 'floor@@GLIBC_2.2.5'
Meh, ignore this one (was: ./configure: line 5972: LT_LIB_M: command not found, as a result of libtool not being installed in the build env).
Is there any platform where cos(3) is not in -lm but in something else, that sc has to use LT_LIB_M rather than just passing in -lm into schismtracker_LDADD unconditionally?
Well, I was going to say because -lm doesn't exist on Windows, but turns out I was thinking of -ldl. But surely there's a reason for the macro existing, and I'd rather use them when they exist instead of having to fiddle with such things later on.
What's the practical difference though? Libtool is installed on most common 'nix build environments, at least I haven't had to deal with any issues like you're encountering. If there's some good reason that I should abandon the macro (other than "I have to install libtool and I don't want to" :) I'm not opposed at all to handling it the old fashioned way.
Ah! Here's the source to the LT_LIB_M macro:
#!sh
AC_DEFUN([LT_LIB_M],
[AC_REQUIRE([AC_CANONICAL_HOST])dnl
LIBM=
case $host in
*-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*)
# These system don't have libm, or don't need it
;;
*-ncr-sysv4.3*)
AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw")
AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm")
;;
*)
It was a small PEBKAC, nothing more. I ran the regeneration due to patching Makefile.am temporarily ( >>>scdev/1504 ), but had accidentally omitted libtool from BuildRequires. (And libtool was recently removed from opensuse's always-installed-by-default list for the chroot±VM build environment to save redundant rebuilds of packages that do not require LT.)
okay :)
Thinking about it, I suppose you could sneak around having to install libtool with a tiny patch to replace the $(LIBM) in Makefile.am with -lm directly, and drop the LT_LIB_M and AC_SUBST(LIBM) from configure.ac.
No I could not, but the devs could :) If the build files (Makefile.am, etc.) are touched, you run into a regeneration phase where you likely need /all/ the tools.
Well, considering ./configure doesn't exist in the first place it'd have to be generated, so whichever distro could apply that patch before running the auto* stuff.
Or something?
I was playing around with this after I found that stongma.it was screwing up on IT 2.14v5. I'll sort the information from easiest to hardest, and I think you might know at least the first one of these.
I'm quite suprised the first one hasn't been fixed yet.
2.14 doesn't actually handle the envelope carry flag, afaik.
Oops, forgot to tag this.
... Envelope sustain-loop bug fixed! Also generalized the envelope position processing code and cut it down to less than half the size.
For the carry stuff, if there's a difference between IT 2.15 and Schism, if you can post a test file along with either (preferably) output of the correct behavior or at least a description of what it ought to do, I'll try to fix that too.
Are you sure that this fix didn't break anything? You got rid of all the CHN_NOTEFADE stuff for volume envelopes!
Also, what's stongma.it?
Yeah, it probably broke stuff... but I'll fix that when I find it :D
Should be easy to find... just play some volume envelope that's not looped and should end with a fade-out (i.e. one that doesn't reach zero volume at its end). I have tried simplifying OpenMPT's envelope handling code before, and that's what has kept me from going further. ;)
Suppose I could check for those cases and return some kind of value that would only be handled for the volume envelope indicating whether or not to trigger note fade.
Or even better: just give CHN_NOTEFADE as another parameter. This should be functionally identical to the old behavior, with the exception that it doesn't cut notes if the envelope ends with a single-node loop at zero volume. Impulse Tracker doesn't do that either, and you can move the node around to mess with the volume, which might even be useful in a live situation.
Hm. Playing with this, it flat out isn't cutting off notes at all.
There we go. Now it should be all right :)
Attached file has a C40 effect on pattern 0. When played with F6 it does some weird pitch shifting effect, or sometimes sets panning?
Changing values of xx can give really weird results including segfaults, F5 shows a bunch of nonsense sometimes, and ctrl-F11 shows error messages.
Probably something similar to >>1444 (could be fixed already even??)
Wtf?!
I was thinking this was something relatively new, like from the last time I messed with the play flow, but it seems like this has pretty much always existed. Bewildering.
I'm trying to compile the source on Mac OS X 10.6.8, got SDL all configured, got Mercurial all setup, got latest Python, managed to pull and update the source just fine, but I get a syntax error when I run ../configure from the build directory. I can't fix a syntax error as I don't know the configure script all that well.... can someone else fix this?
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
../configure: line 5115: syntax error near unexpected token `1.2.10,'
../configure: line 5115: `AM_PATH_SDL(1.2.10, , { { echo "$as_me:$LINENO: error: *** SDL version >= 1.2.10 not found." >&5'
In the configure script it seems to be using a term that hasn't been defined previously:
AM_PATH_SDL(1.2.10, , { { echo "$as_me:$LINENO: error: *** SDL version >= 1.2.10
not found." >&5
echo "$as_me: error: *** SDL version >= 1.2.10 not found." >&2;}
{ (exit 1); exit 1; }; })
I have the proper version installed:
CraniAX:build music$ sdl-config –version
1.2.14
Dunno why this thread never caught my attention. :/
SDL on OS X doesn't come with autoconf files for whatever reason, so you'll need to grab the sdl.m4 from the source and put it wherever the aclocal directory is. Alternately, you can build SDL from source, which ought to put all the files where they need to be.
Schism (just like MPT) does not behave correctly if a sustain loop is found after the normal loop in a sample: When sending a note-off (===), it simply stops. It should continue in the normal loop in that case. To fix that, go to effects.c's fx_key_off(), and add the following line in the "if (psmp->flags & CHN_LOOP) {" block:
chan->position = min(chan->position, chan->length);
And I'll play with this too! :)
Ok, this was not 100% correct.
It must be:
chan->position = chan-position - chan->length + chan->loopstart (or whatever your sample loop start variable is called). See here: http://www.un4seen.com/forum/?topic=12144.msg90903#msg90903
Vol swing is currently applied on the wrong variable; here are some instructions on how to fix it.
effects.c:
find
chan->vol_swing = d * penv->vol_swing / 100.0 * chan->volume;
and replace it by
chan->vol_swing = floor(d * penv->vol_swing / 100.0 * chan->instrument_volume);
Swing amount is a percentage of SV (or SV * IV in instrument mode). floor() is applied to get exactly the same volume levels as in IT. I would assume that you should also apply floor() for pan swing but I haven't examined that as carefully as vol swing.
Now of course, the vol swing has to be applied in a different way as well:
sndmix.c
Find
Yay, thanks! I'll play with this..... some time.
Pretty inconsequential, but still:
If the order list is full, and order 255 is not +++, total song time given by Ctrl-P is way off. Also, the time given differs depending on whether or not something is playing.
Letting the song play through also gives strange results as schism tries to play Order 256, 257, and so on...
Didn't I fix this? I guess not. Maybe I noticed, thought "oh that'll be easy to fix" and promptly didn't do anything.
.... Derr, let's mark it as fixed too.
Enabling default volumes (ctrl-v)in F2, yields zero values with some cases while the volume itself is certainly not 00. I seen it before but never figured out why it does this.
Oh: try searching for it, since it seems to be not very abundant. Load different modules and browse through patterns.
Default volumes are kind of hacked in and I wouldn't be surprised if it's really wrong in a bunch of ways, because it's a feature I don't use myself. I'll have a look at it. Probably shouldn't be too hard to fix.
If you Alt-K from one of those notes to something that has a volume filled in, does it still use the zero volume?
You don't differentiate between sample mode and instrument mode when retrieving the sample slot through song_get_sample(note->instrument), that's why. ;)
In instrument mode, you'll have to look up the sample from the instrument's note map. Impulse Tracker only displays the default volume if there's both a note and an instrument number present - even in sample mode.
>If you Alt-K from one of those notes to something that has a volume filled in, does it still use the zero volume?
No Schism interpolates nicely.
Hey Saga, you also know what you talking about. As a Schism fan I ask: wouldnt you like to help Storlek with developing Schism Tracker? :)
Thank you, I already have an own tracker to develop for which I don't have nearly as much time as I want. Storlek and me are constantly (well, when he's working on Schism, that is :P) exchanging playback fixes, though, so OpenMPT development benefits from Schism Tracker development and vice versa.
Hi. Midi-notes should not be sent by Schism out to midiports, when the channel that the midinote is on, is muted. This kind of forces me to actually delete the notes I've painstakingly put into schism, when I don't want them to be playing. can midinote sending/playing be disabled when the channel the notes are on, is muted?
I hope this is something that can be done without having to have external midi devices to test this out :)
Gotcha! That's kind of stupid that it does that. I'll try to make a blind fix (or rather, a deaf one). :)
When using ./configure --disable-dependency-tracking, as some Linux distros seem to be using during automated builds, one runs into this error:
sh ./scripts/build-font.sh . font/default-lower.fnt font/default-upper-alt.fnt font/default-upper-itf.fnt font/half-width.fnt >auto/default-font.c
/bin/sh: auto/default-font.c: No such file or directory
make[1]: *** [auto/default-font.c] Error 1
Solution is to mkdir the dir before sh is run in the rule.
Done! That was an easy one-liner.