(copypasted from espernet #schism - omitting irrelevant/random junk)
10:33 < delt> oh did i mention that old annoying bug still present on pattern editor
10:33 < delt> when follow mode enabled (scroll lock) keypad + and - fck up when the same pattern occurs twice in a row on orderlist
10:34 < delt> it should behave exactly like ctrl+keypad + and - when not playing&following
10:34 < delt> (and on infopage)
10:38 < delt> it should do the same as on the infopage
10:41 < delt> right now in schism, it stays stuck (can't go past/before) the same pattern twice in a row in order
(end of copypasta)
Oh, i should probably add that IT and ST3, this "stuck" behaviour is what normally happens when trying to rewind ie. skip BACKWARDS across a +++ (or ++ in st3) on the orderlist.
[Moved from /sc/.]
./schismtracker -v dummy
has no effect. When SDL_init is called from schism/main.c, SDL already starts using x11 (see trace). Changing DISPLAY and SDL_VIDEODRIVER environment variable from within schism/video.c thus has no effect, and video_startup() then displays the X11 window.
To start schism in dummy mode, one needs
SDL_VIDEODRIVER=dummy ./schismtracker
162 if ( SDL_InitSubSystem(flags) < 0 ) {
(gdb) p current_video
$2 = (SDL_VideoDevice *) 0x0
(gdb) n
Missing separate debuginfo for /usr/lib64/libXrender.so.1
Try: zypper install -C "debuginfo(build-id)=3b608bb48f593a38ebf82ccaaeac5f89299b1ced"
Why would you even do that? It would be functionally useless, not to mention pointless, without the UI.
It's not useless. It allows for playing files in the background without spending CPU time on drawing an UI. (In a way, I am looking for a replacement to timidity -idt as that and other programs are known to misplay some schism features.)
Drawing the UI takes hardly any CPU at all, especially if you turn on lazy redraw mode.
What sort of computer and video card do you have, and are you sure you've set up the video mode so it's not using an SDL software surface? (And if you do have to use a sw surface for some reason, are you resizing the window? That causes a lot of extra processing.)
You still can't reasonably play anything without a video mode set up, because you have no file browser and no means of providing input, and on top of that you can't reasonably close the program since it traps Ctrl-C to pop up the "are you sure" dialog, which you can't say yes to because you have no interface.
You'd be much better off using something based on BASS if you want a general purpose player, especially one without a GUI.
>You still can't reasonably play anything without a video mode set up,
SDL_VIDEODRIVER=dummy schismtracker -p foo.it
(Thanks for having no faith in me, but Ctrl-C does work.)
Vaio VPCM11 with Intel N10 graphics 1024x600. SDL uses the X11 software driver for some reason. Have not found time yet to check on SDL why it choses that, since Xvideo is available after all.
Listening to one song on permanent repeat is not a reasonable interface for a player. Also, the command line options appear to be more or less broken for some reason. (I rarely use them, so this is the first I've noticed; but your line there does nothing but hang for me.)
Apparently 74e93f14ca14 added signal handling to override SDL's default Ctrl-C behavior. I guess that evaded my notice. Regardless, that's still lousy. You're beating the crap out of a perfectly round peg to try to fit it into this square hole you've cut for it.
Does YUV mode work for you?
>permanent repeat
...working on that...
>Does YUV mode work for you?
xvinfo | grep " id:"
id: 0x32595559 (YUY2)
id: 0x32315659 (YV12)
id: 0x30323449 (I420)I see plenty of YUV modes in that list. What's wrong with them?
Nothing. It seems that "SDL Video Surface" (in Ctrl-F1) is just the default instead of "YUV Video Surface". Also for the GMA3150/N10 graphics it seems SDL vs YUV does not make much of a difference. But I remember it being so on ye olde NV. Maybe I'll get back to testing that.
Clicking at note-offs in the example track is not present in the 2008-03-06 build. It may have something to do with the disabling of ramping? I notice in my test builds from last year where I did not disable ramping, but greatly shortened it, this click becomes more of a small pop.
I'm having some major issues with saving now, whenever i hit Ctrl+S to save, it outputs WAV over the original file. I could get around it at first by hitting F10 then saving over it again, but now it's giving me the error:
Unknown File Type: IT
which, as you can imagine, shocked me somewhat!
hope someone can help, im currently keeping Schism running so that i don't lose my changes!!
thanks
theGarbs
I noticed that CTRL+S does the same thing for me.
I decided to avoid using CTRL+S since it wiped out
a few of my songs. I now use F10 to save my mod updates.
fortunately, I had backed up those songs/wav's.
Shane.
Well obviously that shouldn't happen! I haven't heard problems from people about this stuff until recently so I guess it broke in the Feb. build, and all the file output code was torn out and rewritten so it shouldn't still be broken in the current source. If you're not using any of the stuff that was added in the February build you might be better off going back to the January one until I get a new one packaged.
I have no idea what might have been broken, but the file save and export code was a mess so I'm not fully surprised :P
Something was screwy with MIDI too :)
Today i decided it would be fun to poke around schism tracker some more. I got the source package from the schism tracker page. The mercurial snapshot.
I tried to run the ./configure thingie. It's not part of the package. I am too amateur to find out what to do next by myself.
I thought i could grab a new version before builds are made. I also thought i could check out if some bugs remain in the latest code.
I'm under mac os x. I compiled / installed SDL and all went well.
autoreconf -i will spit out a configure script. Shouldn't be much different on OS X than Linux once you have SDL installed, as long as you have sdl-config in your path. (Getting that might be a minor challenge – I don't remember how SDL works on OS X but I think it's kind of weird somehow)
Thank you, it helped.
I have another error message which is probably related to the sdl-config path.
I'll look into it by myself before asking other questions.
the SDL framework .dmg from libsdl.org does not install an sdl-config script. however, it's not difficult to roll your own. just write a shell script that accepts the same arguments as the usual sdl-config script does and produces the appropriate output, and chuck it somewhere that's in your $PATH.
for example, here's a basic sdl-config i put together recently for my own system. note use of the apple-gcc-specific -F and -framework options: this script assumes that your SDL.framework is in one of the usual spots (/Library/Frameworks, /System/Library/Frameworks, etc)
$cat ~/bin/sdl-config
#!/bin/sh
for param in $@; do
if [ "$param" = "--cflags" ]; then
echo -DTHREAD_SAFE -FSDL
elseYou might be able to get some use out of the one I made for the OS X cross-build that I use (see here), with fixes as necessary to the prefix and target variables, and I suppose also the version. I think it originated from the Linux sdl-config.
On my Dell Studio 15 running Ubunutu Jaunty, unless I am connected to a network (through wi-fi, the only way I connect) Schism won't load. It crashes immediately and gives a segmentation fault. Very odd, I have no idea why it would need an internet connection.
What version do you have?
hi storlek, we've been talking about this a bit on #schism, so here's a bit of a short paste:
9:46 <@distance> either way, is one or the other or both of those switches doable
19:46 <@Storlek> which switches? memory like a goldfish
19:47 <@distance> filter midi note input
19:47 <@distance> 19:29 <@Storlek> how about a switch to ignore midi input
19:47 <@Storlek> that, prolly not, because it seems really really complicated
19:47 <@Storlek> that, yes
19:47 <@distance> - when using midipattern trigger
19:48 <@distance> and switch: say: "when midi pattern trigger received, do you: A) start playback of pattern from
start of pattern B) start playback of pattern from row-cursor-is-on.19:48 <@Storlek> in other words "should midi sync start act like F6 or F7"
19:48 <@distance> exactly
19:48 <@Storlek> well, not exactly, since you can ALREADY switch between playing the song or pattern
preservation of thoughts against irc transience = +1
so basically this is to enhance the functionality of midi pattern trigger.
since its brilliant to be able to already use schism tracker to input notes from a midikeyboard, and have the pattern playback start on first pattern trigger - it is therefore suggested that two (2) switches are created for user usage:
first switch:
when receiving Midi Pattern Trigger - do you start from 1) first row of pattern or 2) row of pattern that cursor is on.
second switch:
when receiving Midi Pattern Trigger - yes/no on "do you filter all midi input?" -mode.
if these two are implemented, it's very easy to guess what i'm going to be asking for next.
OK, track 1, a version where I've done a version number switcharoo by giving them version 8.88 (OpenMPT, IIRC).
ok, it's refusing to load that because it has 257 entries in its orderlist...
And here's track 2, a conversion from dbm.gift or something like that. The samples are missing. For some weird reason, IT214v5 does the same, I'm not sure why. Maybe my converter's rooted. mikmod and vlc/libmodplug load it fine.
None of those samples have flag bit 1 ("sample has data") enabled. Neither modplug nor mikmod adhere to the spec there.
Thanks for that.
I believe I padded the orderlist before I saved it or something like that but it may have added the 255 after the 256th index, which I then dealt with in a hex editor.
Oh, and I should really remember to put that bit in in future.
Oh wait, one more and I'm pretty sure this isn't my fault.
Was just playing around and I stumbled across this corrupted thing.
To make matters even weirder, SussmansClock.it uses the same sample pack and apparently the same tracker, yet works a charm.
Also, it has 2 patterns, not 1 as the status text says.
I use 20100202.
That file is just plain broken. Probably truncated.
I added a lot of old stuff to the repo from ages past – the "old" cvs history from before the directory restructuring, and also merged in the sources to the old tarballs from before Schism Tracker was even tracked in a source control system. The old code has been added under branches "mesozoic" and "paleozoic", respectively. I also merged the first CVS commit with the old tarballs, but it's impossible to do the same with the schism/schism2 cvs transition since that would involve rebasing the entire repository and changing thousands of changesets.
What all that means is anyone tracking hg will now end up with a spare head for all the old stuff; don't be alarmed :)
Hi:
If a song changes speed/tempo (the Axxx Txxx commands),
then samples/instruments lose their volume, and or,
disappear completely.
I suspect that MODPLUG is where the bug is, because
other apps that use "modplug" do the same thing.
Could you please look into this for me, since I am
forced to use WinXP, and I have a whole mess of my
own drum tracks that rely on Impulse Tracker.
Most of my songs change speed/tempo a lot. Without a
bugfix, my future in music is dead.
Have any examples? I can't replicate this at all.
I'll try and bring an *.it mod that does this by Friday.
Thanks:
Shane.
Hello again:
Ok... Here's a backing track to one of my own songs.
Could someone please tell me why it does what I said
it does in Message 938? Notice that as you pass each
speed/tempo change, that samples/instruments drop in
volume or dissappear completely (eventually).
Thanks:
Shane.
There's nothing at all wrong with Schism Tracker's playback here. Your song is cutting the volume in a number of places, uses a bunch of Z00 filters, and has at least one channel muted.
Thanks Ashli.
I'll do what I can to correct this.
I noted that when I play some of my other mods,
that they play just fine, provided that I don't
change the speed/tempo...
Feedback was/is always appreciated. :-)
Take care:
Shane.
P.S. Schism Tracker really RULES! :-)
Well, if you do come across a scenario where something is being played incorrectly, try to reproduce it in a small test-file (i.e. not a full length song) and I'll look into it.
As for the filters, here's a Zxx-stripped version. Were you maybe using IT with non-filtered mixing or non-MMX drivers?
Thanks!
Thanks Ashli:
I stripped out all the Z00 commands by hand.
That was the source of my grief. Now the
MOD plays the way it was intended. Hooray!
I forgot that they were even in there.
I was using them as a memory aid (hard to explain).
I don't even use the midi portion of IT mods....
I REALLY APPRECIATE YOUR HELP/INSIGHT, THANKS! :-)
SCHISM TRACKER ABSOLUTELY RULES!!!!
Shane.
Hello:
Thanks for taking the time to strip out all those
Zxx commands.
Did you make a routine to do that?
I have 15yrs of my own mod work.
Schism Tracker has allowed me to "revive" them.
Thanks a million! :-)
Have a great one.
Shane.
changeset 2087: 5d12eaf07e3b
Why is the screenshot facility being removed?
This was very useful for taking screenshots of schismtracker in fullscreen mode.
It never worked – it always wrote "error writing screenshot: no such file or directory", or "success".
It wasn't a useful feature anyway even if it did work, because you can take a screenshot perfectly fine with whatever existing method your operating system provides.
The .png writer was highly redundant considering libpng exists everywhere, so there's not much use for reinventing the wheel.
The keyboard handler for it was a horribly nasty hack.
On top of that, what is the burning need to take screenshots of the tracker, that it needs to be directly integrated with it? Write more music.
That said, if you can rationally disprove those statements, I might consider adding a proper screenshot mechanism, but I seriously doubt its usefulness.
> It never worked
Yes it did.
> It wasn't a useful feature anyway even if it did work, because you can take a screenshot perfectly fine with whatever existing method your operating system provides
Except when the keyboard is grabbed. Or when you run it without a desktop environment (framebuffer on z2 zipit).
Sorry, I should be more specific. It never worked for me.
It's trivially simple to ungrab the keyboard, and there most certainly are screen-grabbing programs that run on a framebuffer. Indeed, a few of the early screenshots on this page were captured from a framebuffer, because for a time I wasn't even using X11.
I'm entirely unconvinced that such functionality is at all useful enough to be built in.
To hit the point home, here's a screenshot I grabbed, from the framebuffer on my laptop, of Schism Tracker failing to make a screenshot.