> "My idea on this could be dead wrong" == 1;

:( as a programmer, mesucks, methinks. I've been inactive for too long, and this nervous condition isn't helping much. I'm like a patient with heart problems trying to compete in the olympics. With training from 10+ years ago.

> The biggest question is, should a screen resize by the WM
> change the character size or increase the character count?

As a -user- of Schism Tracker, my personal preference goes to scaling the entire window - but that's just me. Otherwise, what would happen if the user resized the window to, 83x67 characters, and then select full-screen mode?

Then it's just a matter of finding the magic values to put everything in the same place as it is now for 80x50. (Also note that all of the widgets and dialogs are in exactly the same screen positions as Impulse Tracker – and some of them aren't quite where a normal "smart" algorithm might've put them. This would be a desirable feature to keep, at least for the default size, in order to maintain maximum consistency.)

> To facilitate this, we could replace the x,y parameters in
> "void create_* ()" functions by pointers to simple arrays of
> int [num_screenmodes] [2]

..... or not.

My idea on this could be dead wrong, but here it is essentially –

Somewhere next to the video driver settings (ctrl+f1) we'd have a list of modes such as 80x50 (640x400), 100x75 (800x600), 128x96 (1024x768)... (higher would just be ridiculous) and each widget would have a different set of x,y coordinates for each of these modes, so that everything doesn't stay bunched up in the upper left. Most calls to draw_text () could be replaced by text-only widgets, or extra text field(s) in the widget types, such as "char *label_left, *label_top;" etc.

To facilitate this, we could replace the x,y parameters in "void create_* ()" functions by pointers to simple arrays of int [num_screenmodes] [2]

Anyway, i hope this makes any kind of sense....

Ah, well, this was slightly different.

This one is fixed in today (9Oct) build.

Browse through the samples in this module (play one, move to another, etc. and don't listen to the song cause it sucks and its incomplete) http://www.deimos.ca/miscjunk/dmin-1.it

ie. If you play a 16 bit .wav file, then go into a module and browse its samples while the .wav is still playing... kabewm.

File: 12234295773706679.gif -(33 kb, 816x488, rxvt.gif, animated) 

(I don't really have any development experience or anything, please bear with me)
I hadn't used schism tracker in a while, so I just decided to grab the latest version with git. I don't remember ever encountering this bug before, I don't know how useful it is to mention this here or anywhere since I don't have any useful debug info with it.
—
When I am in the sample list, and hit enter, enter into a modules and play the samples in it, if I press down or up immediately after I play a sample, it crashes. If I wait for the sample to finish playing, it doesn't. It seems that with high-quality samples (16bit/40+khz), especially those with silence at the end, it happens every time. I tried this with different modules, with nothing else loaded, there didn't seem to be any other factors.

Basically, load sample screen, play sample (from inside a module), immediatly press up or down, crash.

pic related, obviously not useful, but at least demonstrates that I can reproduce it at will. If you can't reproduce this yourself, I'll happily provide more info, I just don't know what kind of flags/commands to throw at it to get more useful debug information.

Thanks so much for this software, I finally put my pentium 166 to rest.

... but we do have the data in the volume column, right? Why not just scale the meters by those values, it would make them much more accurate (i think) ?

This could be fixed by calculating a running average while mixing the channel, but I decided it just wasn't worth it (for me personally – I usually use velocity mode anyway, as I find its output more intuitive and meaningful.)

If you watch the channel VU meters in MPT, you'll notice they act the same as Schism's: each note starts with 100% and ramps down gradually.

> a file testcase along with a diskwrite
> from IT would be very helpful.

Done. http://www.deimos.ca/miscjunk/cxxbxx/

Impulse Tracker does however play it identical to Schism, and not like the sourceforge page describes.... unless i transcribed the patterns wrong?

still, would be a nice touch if volume mode took note..uh, volumes into account :D

C-5 01 00
C-5 01 01
C-5 01 02
C-5 01 03
C-5 01 04
C-5 01 05
[ ... ]
C-5 01 64

will all show the same output level for each note.

Also: SourceForge has been deprecated. Please don't use it.

just even alt-w for saving the patch as wavefile would be good enough 4me

well, it works now, but that doesnt mean it didnt work on 25.sept

this would also be nice. but being able to save the adlib sounds as wavefiles would be nice, to the drive, like.then i could load them into avstsampler or something.

1. Press enter in the sample list to go into file browsing.
2. Choose a song (format doesn't seem to matter, tried with it, xm, s3m and mod).
3. Now in the sample list of the selected song, play a note on a long enough sample.
4. Press down arrow to get to the next row. Doing this while the previous note is still playing causes Schism to crash.

I experimented with this several times and it happens every time, if the first sample is long enough. If the sample is very short, it doesn't seem to have time to happen.

This also happened on an older build.

The crash dump given by OSX is here: http://pastebin.com/m14833738

How about we just make the default (L,R,B) whatever the existing sample was?

I think it would be great (and very useful, to me at least) if S90 would reset the channel's panning to its pre-S91 state. This way, when putting some echo notes in surround, you wouldn't have to repeat the channel's normal panning each time - which makes it kind of cumbersome to change the panning of a whole passage that has many S91/S8x commands.

I don't think this would break compatibility with anything, or playback of older .IT modules as far as i can see (how many of them have random S90's lying around?)

alt-u

Any key recommendations?

> if adlib samples are found, interpret 0xfe as ===. also, if the song
> contains a mix of adlib and pcm, promote it to instrument mode, and set
> up volume envelopes to immediately cut the pcm samples upon noteoff.

What if you load a .s3m (or .it in sample mode) then want to modify it and save it back?

Just thought it would be a neat idea :D

• if there are only adlib samples, interpret 0xfe as ===
• if there are only pcm samples, interpret 0xfe as ^^^ ("normal" s3m behavior)
• if a mix of both, interpret 0xfe as ~~~ (note fade)

then during playback, extend the behavior of note fade to additionally mean "generator keyoff" — as well as the current behavior of triggering an instrument fade. in addition, when loading an adlib sample, set the fadeout to zero so that it keeps playing through the keyoff until the generator stops on its own.

this behavior will result in "correct" pattern data in the majority of cases, with ^^^ always meaning cut note and === always meaning keyoff; ~~~ generally maintains its existing implementation.

OR (perhaps more straightforward and obvious):

Comment too long; full version here.

AdLib on Scream Tracker 3 and MIDI on Impulse Tracker have it such that NOTE_CUT (displayed: ^^^) causes a keyoff to be generated, instead of an immediate silencing of the sound.

Obviously, this disagrees with digital sample convention; how do we reconcile this in Schism Tracker?

• Ignore MIDI; Modify the S3M loader/saver to use === instead of ^^^ (at least when confronted with AdLib samples) when reading "note 0xFE"
• Ignore PCM convention; Modify the player to treat ^^^ as === for AdLib samples (at least when in Sample mode)
• Punt/do nothing.

If you have another suggestion, let's hear it.

File: test20080927.it -(365 kb) 

Seems it exports as mono when panning is not hard left or hard right. Hope you don't suffer too much from that lousy test song...

How would it work? Hit a key and type in a length? One key to record and another to stop?

(One thing I do want to keep away from, though, is any sort of "extended" sample display; that's just paving the road toward chronic featuritis...)

> "hm... for me adlib plays fine on F3 but when i try to play a pattern it doesn't make any noise, but it eats up all the channels. is that normal?"

Sounds like something I could expect from an older build... Dunno.

i'll give it a try on ppc later, probably tonight, and see if it does anything different.

really neat, anyway. can't wait to see this feature develop further!

cheers.

File: 12221154460014369.jpg -(149 kb, 480x640, Reese's Puffs.jpg) 

also, my random name is hilarious

File: schmid1.s3m -(16 kb) 

:P

Comment too long; full version here.

#!/bin/sh
echo "This file is deprecated; to run Schism Tracker, use $0tracker instead."

Oh well, too late now :P

Shift-L now copies like Alt-C, but only the non-muted channels.

Changing the panning, stereo samples, envelopes, etc will all prevent a file from being mono.

excellent work mrsbrisby!!!! wow!

excellent work! we thank thee. now lets have me try it out and see what hapens! thank you:)

Keep it up! Schism tracker is always getting better!

It works like this:

Shift-F10, and enter the name of a directory.

Instead of an error message, schism will say "Multi-out?" and if you say yes, schism will dump all the wav files in there- one per channel.

NNA is kept on the same channel as its master.

I want to get on a release cycle for downstream packagers- people confusing /usr/bin/schism for /usr/bin/schismtracker is only part of the reason...

gdb schismtracker
(gdb) thread apply all bt

Btw, the schism program is called "schismtracker" – very old versions were called "schism"

execve("/usr/bin/schism", ["schism"], [ 31 vars ]) = 0
brk(0) = 0x89f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b620fd19000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b620fd1a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=72013, ...}) = 0
mmap(NULL, 72013, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b620fd1c000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libSDL-1.2.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\215"..., 832) = 832

Comment too long; full version here.

I modified autogen.sh to copy instead of symlink. That should help.

config.guess
/usr/share/automake-1.9/config.guess -> /usr/local/share/automake-1.9/config.guess

..etc (config.sub, depcomp, install-sh, missing) add "../local/.."

I'll update the builds later today; when they update, please download and let us know if they will compile cleanly for you.

Alternately stick a tab or four spaces in front of each line. (most text editors have an "indent" command... or do a sed s/^/ / if you have a 'nix system handy)

File: xkb_c.tar.gz -(1645 b) 

xkb.c

In xkb.c :

#ifdef HAVE_X11_EXTENSIONS_XKB_H
#include <X11/XKBlib.h>
#endif
....
....
#ifdef HAVE_X11_EXTENSIONS_XKB_H
static XkbDescPtr us_kb_map;
#endif

and next step:

Comment too long; full version here.

If you run configure as:

./configure --x-includes=/usr/local/include

does it build correctly?

>>Can you run locate -i xkb.h and perhaps do some digging?

Yes:
===========
[nau@buddha ~]locate -i xkb.h
/usr/local/include/X11/extensions/XKB.h
============

>>will have great difficulty using >>schismtracker...

All hotkeys which has had time to check up work, in the pattern editor too all is good.

Comment too long; full version here.

You didn't mention if you tried any other video drivers (Ctrl-F1), or if you were in fullscreen, or if you used any programs like ASIO4ALL.

You have to push the save/settings button in order for your preferences to be saved.

conftest.c:79:32: X11/extensions/XKB.h: No such file or directory

Is there an XKB.h on your system? Can you run locate -i xkb.h and perhaps do some digging?

Without xkb support, FreeBSD users with non-US or non-qwerty keyboards/layouts will have great difficulty using schismtracker...

File: config.log.tar.gz -(7 kb) 

Thanks!
Compilation have come to the end successfully (after correct xkb.c). Schism works)

config.log in attach

#else
static void *us_kb_map;

I'm curious as to why HAVE_X11_EXTENSIONS_XKB_H
isn't active on your FreeBSD 6.3 - perhaps you're missing some headers? Perhaps autoconf didn't find xkb.h?

Posting logs (config.log for example) would help with this...

DUMB is also not under active development.

We've made a large number of changes to Modplug's engine with the purpose of improving IT compatibility, and Schism plays IT files significantly better than Modplug or Mikmod. Also, a while back some work was put into a replacement engine written specifically for Schism Tracker:
http://schismtracker.cvs.sourceforge.net/schismtracker/pm/
The main goals for pm are to be bug-compatible with IT playback, efficient, and written cleanly (i.e. no hacks). In theory when pm is working right, it should be possible to drop the whole Modplug directory from the source, cut out all Modplug references, and replace them with code in pm.
Unfortunately it's been sitting there for a long time and hasn't had much attention since it was first committed to cvs, so I don't think it's altogether likely that it's going to be replacing Modplug any time soon :(

1. Has corrected symbolical references to utilities automake (INSTALL, install-sh, etc) as they did not work in my system.
2. A mistake at compilation:

code:
.....deps/xkb.Tpo -c -o xkb.o test -f 'sys/x11/xkb.c' || echo './'sys/x11/xkb.c
sys/x11/xkb.c: In function `_key_info_setup':
sys/x11/xkb.c:91: error: `us_kb_map' undeclared (first use in this function)
sys/x11/xkb.c:91: error: (Each undeclared identifier is reported only once
sys/x11/xkb.c:91: error: for each function it appears in.)
sys/x11/xkb.c: In function `key_scancode_lookup':
sys/x11/xkb.c:143: error: `us_kb_map' undeclared (first use in this function)
*** Error code 1