1

(58 replies, posted in General Discussion)

kat.it by zebra: http://battleofthebits.org/arena/Entry/kat/12138/

datamask is a source-only tracker module netlabel

edit: also, a lot of the old releases on inpuj are source-only tracker modules

sorry for the radio silence—builds are finally available for windows & linux, but no osx.

https://github.com/schismtracker/schismtracker/releases

@jmph – it would be awesome if you could help out (read: do all the work) with osx builds! #schismtracker on irc.esper.net is probably the best place for real-time discussion, but github issues work too. i don't normally check this bbs very often (and i don't think sandneil does either).

i've never used osx and i didn't write the instructions, so no idea how involved that is, or whether it even works.

actually, i know a couple people have definitely had success building on osx from this repo. but i'm no osx user either :) it would be great if we had someone we could rely on for osx builds, because i think all our developers (org members or otherwise) either run windows or linux.

yeah, should have mentioned those – i only meant that money is tight here as well

edit: actually, didn't know about the bandcamp

in other news, storlek is back on the dev team! https://github.com/schismtracker

that looks like the build that scannerboy linked earlier, which doesn't include the dylib. (past "official" releases of schismtracker have included the dylib, and we plan to do so with ours as well). also, scannerboy's builds are from storlek's hg repo, which is now several bugfixes behind our git one :Þ

if it's shifted a few ticks, is it possible that the midi timestamps (that schism is sending) are wrong or that there's a latency issue?

the start message and the clock messages are handled by completely different parts of the code, so i don't think there's any causal relationship there. the number of clock messages sent is directly tied to the number of samples that the mixer outputs, so i don't think there should be a problem there either, but i'm investigating further.

edit: also, what software/hardware are you syncing to it? we'd like to collect that sort of info in case something goes wrong in the future.

scannerboy wrote:

It looks that currently schism sends one midi clock message (F8) every eigth row and it should send 6 midi clock messages on every row.

I think that the easiest way to test it would be to connect an external sequencer and check if it stays in sync.

ok, sending one clock message every eighth row is definitely wrong. the midi spec says that 24 clock messages should be sent per quarter note, so six messages per row is perfect if you're assuming that four rows correspond to one quarter note. which is reasonable.

edit: i said a bunch of stuff here before about how sending one clock event per tick would probably be easiest, but it looks like that's not the case. more info to come.

.IT nerds might find this interesting: https://github.com/jangler/schismtracker/issues/3

as far as i'm aware, DUMB is the only player that emulates this pathological case correctly.

edit: tested the latest version of xmplay today, and xmplay gets it right, too. kudos.

@PULSELOOPER – ah sorry, i thought you were being facetious :~)

but i agree with sandneil. it's certainly doable, although new features aren't our top priority yet. if you want to make a feature request, the best place to do it is on the github issue tracker, since in n months we aren't likely to remember that thing someone said on that forum thread that one time.

schismtracker is designed to replicate IT's look and feel, but being an exact 1:1 replica isn't the goal. schism adds new features like adlib support (present in ST3 but not IT) and some things that are useful outside an MS-DOS context (you didn't need a key binding for "toggle fullscreen" back then).

~actually we plan to integrate schismtracker with The Cloud so that you can access all your samples across all your devices~

archive.org is missing the last year of posts on the /scdev/ forum, meaning that all the issues and patches that had been posted since schism development stopped are quote, lost, end quote.

most likely that content still exists somewhere, and hopefully in a location that is still accessible by storlek or another contributor. maybe someone who has a twitter account and isn't afraid to use it could ping them about it

in the absence of any feasible way that i can think of to support storlek, i'd at least like to keep the great software they developed accessible.

to this end, and since schismtracker is open-source and GPL-licensed, i've forked storlek's schismtracker repo on github, replicated the latest commit from the bitbucket repo, and ported most of the old schismtracker.org wiki to github as well.

some of the download links on the wiki still point to files that are only available via archive.org. a couple of friends and i plan to build some up-to-date versions of schismtracker for the most common platforms and make them available via github releases.

integrating some of the untouched patches from /scdev/ is also on the to-do list.

if you're code-savvy and would like to chip in, feel free to open issues and make pull requests as appropriate. also feel free to help storlek out if you can :(

there were a bunch of promising-looking patches on /scdev/ that hadn't been integrated yet

including one by me that warns if you if you save a module containing adlib instruments as an IT

written after much grief over many instances of that mistake