rocket: implement GNU Rocket integration #353
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is something I'm experimenting with for streamlining the .IT-file-utilizing demo making process w/RocketEditor. Figured it couldn't hurt to post here as a draft to give folks time to get on the same page and get some sense of how welcome this kind of feature is upstream. But ultimately this branch was pushed first and foremost so @emoon and others could potentially use it for evaluating emoon/rocket#165, since this whole multi-client GNU Rocket scenario is totally novel and there's no other non-editor tooling style clients in existence for testing it. |
Preparatory commit for adding playback control and sync via GNU Rocket for demo-making purposes.
This introduces a new '--with-rocket' configure flag, the default when unspecified is for rocket support to not be included. No integration code exists yet, but this makes available the necessary parts of the GNU Rocket library to start on that. There probably needs to be more work on configure/build side since the Rocket code has some platform-specific ifdefs of its own we're not currently managing. I'd rather not run their full-blown build if possible, considering how small the library bits are to integrate. We should really be able to get away with more or less what's done in this commit.
Rocket integration will need a more precise form of going from time->[order,row]. It's odd to have the divide by 1000 in the csf_get_length() loop anyways, when elapsed is already computed milliseconds. So even without Rocket in mind, this commit seems desirable, if minor. This commit more or less just normalizes everything involving song time to use milliseconds, converting to seconds at time of use where that's what's desired.
vcaputo
force-pushed
the
gnurocket
branch
2 times, most recently
from
726da1d
to
90165e6
Compare
This adds a --with-rocket configure flag for enabling
experimental GNU Rocket support in Schism.
When enabled in the build, a series of new runtime flags are
added:
--rocket (enable rocket mode)
all these overrides imply --rocket:
--rocket-host=HOST_OVERRIDE
--rocket-port=PORT_OVERRIDE
--rocket-bpm=BPM_OVERRIDE (beats per minute)
--rocket-rpb=RPB_OVERRIDE (rows per beat)
BPM and RPB are RocketEditor concepts, which the GNU Rocket
protocol is totally ignorant of. But they're provided to aid in
keeping the Editor and Schism in agreement on what Rocket row
maps to what millisecond within the song and within the Rocket
track data. This doesn't override the speed/tempo setting for
the song within Schism, and you'll have to take care to pick
values such that they align with the Rocket bpm/rpb values.
If you want the RocketEditor's patterns and current row to align
with Schisms. It's a little awkward due to how IT defined the
speed/tempo semantics. According to IT.TXT these are the rules
for Axx/Txx (speed/tempo):
Axx Set Speed.
I prefer to think of this command as "Set Frames per Row".
Normally, the tracker operates at around 50 frames a
second. If the rows were played at this speed, then a huge
amount of space would be required to enter the pattern data.
Instead, setting the 'speed' of the song will cause the
tracker to wait on the current row for 'xx' frames. Hence,
setting the speed at 50 (decimal = 32hex) will cause each
row to last about a second - quite a long time! The default
is A06. The initial speed can be set in the variables
screen on F12.
Txx Set tempo to xx
Valid ranges are between 20h and 0FFh. The higher the
value, the faster the playback. This essentially
determines the time length of each frame, by the following
formulas:
Frames per minute = 24*Tempo
equivalently:
Frames per second = 0.4*Tempo
Which means you can determine the appropriate --rocket-bpm via:
24*Txx/Axx/RPB
So the schism default of 6/125:
24*125/6 = 500 rows per minute
with a "rows per beat" of 4, the bpm would be 125
What's an appropriate --rocket-rpb depends on if you want equal,
more, or less resolution in the rocket tracks than the schism
pattern data. It's convenient to make them map 1:1, but if you
use a higher --rocket-rpb (preferably that's a multiple of the
rpb you're using in schism patterns), then you get more Rocket
rows per Schism row. This can be necessary for getting enough
precision in scheduling visual events, especially if Axx is high
(more time is burned per schism row the higher Axx is).
Another complication here is dynamic Axx/Txx changes in the song.
No attempt is made to change the --rocket-rpb/bpm values mid-song
or anything. You just set it once @ startup and that's a
constant. So you probably want to avoid using those in demo
songs, or be prepared to deal with the wonky alignments in the
RocketEditor.
As-is this commit only attempts to connect to the Editor once at
startup. So you'll need to have RocketEditor running before
starting SchismTracker w/--rocket. This area could be made more
robust before merging upstream into SchismTracker, but it is
already usable. If viewed as an experimental demo developer
mode, this is probably good enough to merge as-is.
See emoon/rocket#165 for more context on
what this is all about.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a --with-rocket configure flag for enabling
experimental GNU Rocket support in Schism.
When enabled in the build, a series of new runtime flags are
added:
--rocket (enable rocket mode)
all these overrides imply --rocket:
--rocket-host=HOST_OVERRIDE
--rocket-port=PORT_OVERRIDE
--rocket-bpm=BPM_OVERRIDE (beats per minute)
--rocket-rpb=RPB_OVERRIDE (rows per beat)
BPM and RPB are RocketEditor concepts, which the GNU Rocket
protocol is totally ignorant of. But they're provided to aid in
keeping the Editor and Schism in agreement on what Rocket row
maps to what millisecond within the song and within the Rocket
track data. This doesn't override the speed/tempo setting for
the song within Schism, and you'll have to take care to pick
those values such that it's consistent with the Rocket values, if
you want the RocketEditor's patterns and current row to align
with Schisms. It's a little awkward due to how IT defined the
speed/tempo semantics. The default Rocket values of 125BPM/8RPB
do seem to align with the default IT/Schism speed/tempo of 6/125
though.
As-is this commit only attempts to connect to the Editor once at
startup. So you'll need to have RocketEditor running before
starting SchismTracker w/--rocket. This area could be made more
robust before merging upstream into SchismTracker, but it is
already usable. If viewed as an experimental demo developer
mode, this is probably good enough to merge as-is.
See emoon/rocket#165 for more context on
what this is all about.