
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.
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.
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.
Schism is probably looping one too many or one too few samples each end of a ping-pong loop. Probably only matters with chip loops, where it causes tuning problems.
Attached file should not sound out of tune when played.
This is the correct behavior.
Seems the issue is more complex than it first appeared.
At a playback rate of 44100, example file plays a little detuned, but nothing too serious. (It is noticeably a little off when directly compared to IT's output.)
At 48000, the rate I was using when I made the report, schism plays it very out of tune. C7 is very flat against C4 of the same sample.
Changing that PINGPONGOFFSET define in mixer.c to 1 changes the sound a little, but I can't say if it's an improvement.
In case you want it, attached zip has wav writes of pptune.it from IT (mono diskwriter in dosbox), schism default, schism with PINGPONGOFFSET=1, and XMplay, at both 44100 and 48000 Hz.
I'd bet that this is rather related to libmodplug's inaccuracies in frequency calculation due to using "periods" rather than real sample frequency.
>>1457
Doesn't that only cause significant problems with Amiga tuning or after a lot of pitch sliding?
>>1458
It can cause audible tuning differences in various ways, so this was a actually shot in the dark.
>>1472
I see. I'll retag this one then. I still haven't looked at that zip file :(
If the problem is in fact the periodic tuning, it'll be a big pain to fix since that'd require rewriting almost all of the code that handles pitches, which is like half the player.
>>it'll be a big pain to fix since that'd require rewriting almost all of the code
Understandable. Just so long as it's not my ears that are broken...
Hi, I'm using Schism Tracker - build 20110101 - for OS X. (I'm new to trackers, and not new to software like Ableton Live and MAX/MSP – but love the simplicity and stability of the tracker mindset.)
I have opened some existing files and seen Surround used. I also see that there is an Effect that will put a track into Surround mode. But, I'm left with questions:
2) Did the original Impulse Tracker support sending things to more than 2 channels, or was its definition of "Surround" the same thing discussed in Question (1)?
Thanks for any help :)
rs
All "Surround" does is flip one channel (the same way Alt-I does it). Neither Impulse Tracker nor Schism Tracker have real support for more than two channels - it's somewhere buried on the wishlist but even when that gets implemented, the S91 surround will continue to do the same thing it's been doing for compatibility's sake.
I think there's some (Dolby) hardware out there that can recognize inverted data and route it somehow to another speaker, but I haven't used such a system so I have no idea. (IIRC, Jeffrey Lim didn't know if it actually worked either...)
That was actually the idea behind surround mode, yes - some Dolby hardware can send the "surround" channels to the rear channels. If you use OpenMPT for example and set it up in quad surround mode, it will indeed send surround channels to the rear channels. XMPlay might do something similar, but I haven't tested it.
Note that many IT modules were not created with real surround speakers sets in mind, so many use the surround (or rather phase inversion) effect for stereo tricks rather than real surround positioning.
>>1471
That's because OpenMPT redefined what S91 actually does if you have 4 speakers – instead of inverting phase, it reroutes it to different channels in software. Schism Tracker doesn't bother with that and just does what Impulse Tracker did. (I'm almost certain that IT didn't have support for surround cards.)
For whatever reason, even though I have rear-out on my sound card, the same audio still goes to all channels... except for DVD playback. I have no idea how that works, but the net of it is that I can't test what any of this does. :\
Probably just my ignorance and not a bug, but I don't know where to put it otherwise. I use the Schism Tracker version built on 2011-01-01, on Windows XP. I set the config file to export WAV files to 96kHz and 24 bits, because I want to do some post-processing on the WAV in Audaucity. However, when I import the WAV file in Audacity it just plays as static. I tried importing it as RAW data in Audacity, but that doesn't make any difference (I tried different settings for endianness, but it makes no difference). I can't play the WAV file in Windows Media Player either (it asks for a codec). If I try to load the WAV in Schism itself, it also plays just static. Exporting as a 32 bits WAV gives a similar result. Exporting as 16 bit works fine, but I really want to work on a higher bit rate. Is there any other way to go about this, or is it really a Schism bug?
Yeah, Schism Tracker never really had support for anything higher than 16-bit. It pretends to but fails miserably at it. (There's also a kind-of-related bug about 24/32-bit wav files not loading correctly.)