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")
;;
*)
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.
Hello! I am wondering if anyone has had any luck connecting a midi controller to their Wii in order to trigger samples and/or instruments in Schism Tracker. I have tried to make it happen with an m-audio midi-to-usb adaptor, but it isn't detected under midi ports in the midi setup tab. Will the Rock Band 3 midi adaptor help, or is this just not one of the features of Wii Schism Tracker? I'm cueing drum tracks and accompaniments with a Dance Dance Revolution mat, and the latency is practically non-existent. It would be very cool to get that same responsiveness triggering samples from the Wii (like the ModPlug instrument tab without the latency) using a midi keyboard or midi taurus-style pedals. Can it be done?
That's never something I played with. Considering that last I tried to build the Wii version, the keyboard didn't work, and I also haven't a working installation of devkitpro anymore, I don't really foresee much in the realm of improvements on that front unless someone else picks up on the development (hint: I'm totally ok with that). Unless I missed some key bit of Wii development, I'm pretty sure you'd basically have to write all the driver code to handle a USB MIDI device first... much of which you could possibly lift from Linux drivers, but still, that's icky code to write :)
It'd be pretty dang cool though, so if someone else does happen to have the interest in doing it, I'll apply their patches.
Hi,
I have found a situation where Impulse Tracker and Schism Tracker differ in playback. The situation begins with a note playing in a channel. In the same channel, a new note with a different instrument is then played. This new note has a Gxx effect.
In Impulse Tracker, the new note will play, inheriting the frequency of the old note. Presumably, this inheritance is caused by the Gxx effect.
In Schism Tracker, the new note will not play at all, perhaps because it seems "wrong" to pitch slide across instruments.
I have attached a module (bendtest.it) which isolates the situation. With Impulse Tracker, a note (C5) plays, followed by a slide to D5. With Schism Tracker, the first note will play, but a slide is not heard. This situation appears in razor-ub.it (http://modarchive.org/index.php?request=view_by_moduleid&query=68855) and causes missing notes in channels 11 and 12 near the end of pattern 13.
Schism Tracker version: win32, 20110101 (also confirmed with Linux i686, 20120105)
Impulse Tracker version: v2.14
Thanks for the test case.
This probably has to do with Modplug calculating everything by periods instead of frequencies, which actually causes a ton of dumb bugs. I'll have a look.
I vaguely remember there was something about this in IT's documentation - and in ST3's documentation as well if i'm not mistaken.
....otoh, i also remember reading (at least the ST3 readme file) and asking myself "what kind of stupid idiot would want to bend/slide across samples of different frequency?"
... then again, this would be quite relevant in creating ultra-realistic violin tracks =)
The way I use SchismTracker a lot is by tracking drums, bass lines, synthpads, various effects, etc, then exporting each of these instruments as seperate WAV files. The way I do that is by setting the volume of each instrument to zero, except for the instrument(s) I want to save, and then save it as a WAV file. I repeat this step for each instrument, and then load the seperate WAVs into Audacity to do some post processing like adding reverb, do some equalizing, or adding other effects.
Obviously this process can get a bit tedious when the track has many instruments, so some kind of way of selecting which instruments to save as WAV would be nice to have for me. I realize this is a pipe dream type of request, and I might be the only one who uses Schism Tracker in this way. Still, some way to diskwrite to WAV only selected instruments would be greatly appreciated.
That's actually somewhere on my infinite todo list.
not exactly connected to schism-tracker but magicfish postmod is the tool you want to render wav based on track or instr from it files
the official site for the program is down but if you cant find it on google just let me know and i will send it.
>>1497
Per-channel already is implemented, y'know. Shift-F10 :)
XMPlay can render instrument-wise too. I can't find any details about Magicfish, but I know XMPlay generally has excellent quality/accuracy :)
Oooh, XMPlay can do this? I have to check it out then. I'd still love to have it in Schism Tracker, but it would be a fine solution until then.
2) ctrl-o (overwrite,new,cancel) - i.e. if you're overwriting a sample that exists, you can instead select New and it'll be diskwritten to a new sampleslot (unless if all 99 sampleslots are in use)
3) Ctrl-O in F3 - diskwrite currently playing pattern to currently selected sampleslot.
#2 I think I understand, and I think that's in my scratch-notes file somewhere.
As for #3 I suppose the Ctrl-O could be generalized to a global key rather than implementing it per-page. At least, I don't think there's anything that's stopping that key from being global...?
The first thing, tbh I have no idea what you're asking for.
Oh yeah, also have some bug category stuff, for making Ctrl-O a global hotkey.
OSX support - implicit quit from cmd-tab. cmd-q will quit schism instead of just putting it to "quit yes/no" mode?
if something hasn't been saved, it will ask "do you want to save the current song" (=the usual thing).
every other application will quit on cmd-tab-cmd-q, but not Schism :)
Still don't quite grasp this. You want to quit with no prompt at all, but only if Schism Tracker has just received focus? That would be complex to implement, since then focus-in would need to be somehow processed alongside the keyboard handler...
Would be simpler just to stuff in an option to not prompt before quitting, imo.
schism tracker doesn't receive focus, but does get a quit signal.
an option to not prompt before quitting (unless if there's something to save) would probably solve this fully.
Okay, just saw this in action on a Mac. That's a really weird feature.
I guess I could add a "don't ask before quitting" option. Bump this if I don't remember to put the bug meta stuff on it when I get home Monday.
>>1433
actually, now it's monday 02.24am gmt+2 time over here in finland. will that do as monday for you, Pierre Dodson?
woo! stuff has been acknowledged! where do i see all the stuff that's been acknowledged?
>>1448
I keep forgetting to do that or am not anywhere near my computer when I have time, and I don't have time when I'm at my computer because I'm busy with other things. Sorry.
Hi.
If you set Schism Tracker to send midi Output to a midiport, switch to Instruments mode, go and edit the Instrument and set a midi channel, and go into F3/F4 or F2 and press a key - the key is not sent.
I spent some time fiddling around with this until I realized that the only way for the recorded-in midi to be sent out to a midi-port, is if playback is on and if the playhead wishes to play a specific row content.
Is a keyjazz possibility for midi-ports possible? The only issue I can perceive is having to have a GUI element which allows for setting the length of the note being toggled - so that it is not just a hung note (altho, this would be intriguing with some synthesizers + software + arpeggiators)..
> Is a keyjazz possibility for midi-ports possible?
Yes.
Likely? Not unless I can figure out why ALSA MIDI apparently stopped working with Schism on both of my computers.
Hung notes wouldn't be problematic, as soon as you let go of the MIDI key, it would send a note-off, just like on the PC keyboard.
wonderful! wonderful! :)
what can we do to assist you with midi?
>>1463
Step 1, wait until I have free time to do things like goof around with ALSA MIDI, because currently I don't.
Step 2, wait while I goof around with things and figure out why it doesn't work.
Alternately, find other programmers who are willing to submit working patches. :)
what if you had a computer which gave midi out without alsa midi mess?
>>1465
I'm not sure! It might be that new computer I have been wanting for quite some time but not having the free cash to buy, in which case it'd probably be running Win7, and also could be useful for fixing a lot of Windows-related issues that I can't otherwise debug ;)
I'm running build 20110101 on OSX 10.5.8
When I open the sample browser, and try to load a file, the list of files quickly disappears one by one, leaving only the directories. When I navigate into a different directory, once again, the files are displayed for a few seconds and then vanish.
This problem prevents me from loading any samples into the program. Is this a known issue?
It seems very obvious, but are they supported samples and are they samples trying to be loaded from f3? Does it also happen when you only browse your libraries (ctrl-f3/f4)?
The only times I have what you describe is when I enter a directory that doesnt have what Schism searches for. Happens only in dirs with many files.
>>1485
The sample library doesn't (shouldn't?) remove files from view, it just reads them as raw data if you try to load them.
The behavior here sounds to me like you're trying to use the instrument page (F4) instead of the sample page (F3). If you're loading a .wav file or similar, you need to be on the sample list. The instrument list is for setting up multisample instruments, envelopes, and stuff, there's no actual sample data there.
i think you guys are right. i am trying to load samples via the instrument library. /facepalm
thanks for the help!
Schism Tracker doesnt find a suitable audio device, so it uses the dummy driver. /dev/dsp exists but running with an "-a /dev/dsp" flag doesnt help. I currently use alsa with proper modules and oss plugins loaded.
I used the 1/1/11 build and a self compiled hg build per wiki notes. Both had the same result.
I have no clue what to do next.
shotgun approach, maybe one of these will work:
schismtracker -a alsa:default:0schismtracker -a alsa:dmixschismtracker -a oss:/dev/dsp
aoss schismtrackeraoss schismtracker -a oss:/dev/dsp
(get aoss from a package called alsa-oss, probably)
lsof | grep dsplsof | grep snd
end or kill any processes that come up from these commands
Thank you. You aim very well with a shotgun! First and last shot in the bulls eye. Pick a teddy or pony at your liking :)
I'll take the bear!
Instead of typing the -a parameter every time you can just add it to ~/.schism/config under the [Audio] section, i.e.driver=alsa:default:0
Yep, that'll do it. (For good measure, here's a link to the relevant documentation.)
I have had issues with the dmix driver giving terrible latency and completely ignoring the requested mixing buffer settings (among other issues). At present I have a buffer size of 256 set in the config, but with -a alsa:dmix Schism Tracker winds up with a 1024-sample buffer. I've even seen dmix hand out 4096 samples, which is particularly bad. My answer to this was to require 100% attention to the audio hardware unless you explicitly request otherwise.
... and you know that >>1470 isn't me, because what would I do with a silly bear ;)
>>1475
Actually -a alsa:dmix gives me a message about "Couldn't find any hardware audio formats". I think I have all my sound configs set up properly, but with audio on Linux, who can tell... In any case -a alsa:default:0 gives me nonexclusive access, and also gives me a fixed buffer size, tied to the sample rate. In my case I'd actually want it higher, but I'll manage.
>>1476
My choices were bear or pony! It's not like I was offered a car or a video card or something ;p
>>1478
Really? Interesting.
You know, you can fiddle with the buffer size if you want. It's buffer_size= in the [Audio] section of the config. I have meant to add a slider thingy to adjust it in-program but I'm really lazy when it comes to changing the GUI because it was coded stupidly in the first place. (what was I thinking?! oh right, I wasn't.)
I just tried alsa:dmix versus alsa:default:0 on my desktop, and both of them ignore the buffer size I request, giving me 1024 samples.
>You know, you can fiddle with the buffer size if you want.
Yeah, but it has no effect with alsa:default:0 or any other audio device setting that works. Otherwise I crank it to 2048. But I favour multiple access to audio over high-latency stability.
1024 is the buffer size I get at 48 kHz, and it's actually less prone to underruns, but the screen refresh is a lot worse. Also tuning problems as discussed in >>1447
BTW, out of curiosity, how much coding experience did you have when you started on Schism Tracker?
>>1482
Not enough, lol.