For sake of simplicity, we'll call these steps: compose, save, compile, compress.
Both synths also constrain what you can do in the synth in different ways and have different costs for using certain features. In the case of Clinkster (from the docs and summarized):
- You can use per-note velocity, but no other in-track effect commands.
- You can adjust the volume and panning of tracks using the Volume/Panning Track DSP, the post-DSP volume/panning, the mixer and the master volume.
- The maximum velocity you can use is 7F
- You can use the Delay effect (under Track DSPs) with these restrictions:
- The "L Feedb.", "R Feedb." and "Send" sliders must be at the same position.
- "Mute Src." must be off.
- No L/R Output Pan.
- If you use the Delay effect on multiple tracks, you must use the exact same parameters on each track.
- During conversion, each note column in a track will become a separate track in the converted music.
- For each track, each tone / length / velocity combination counts.
- If the velocity is omitted, it is 127.
- Optional features used in the music has some cost in terms of the code size of the player.
- The options are:
- SINE, SAWTOOTH, SQUARE, PARABOLA, TRIANGLE, NOISE:
- VELOCITY: One or more notes have velocity less than 127.
- LONG_NOTES: One or more notes are longer than 127 rows.
- DELAY: The delay device is used.
- PANNING: One or more tracks have non-center panning.
- INDEXDECAY: Some instrument has IndexDecay different from 0.
- GAIN: Some instrument has Gain different from 1.
It's worth it to understand that any of the restrictions that say "you can" end up adding bytes to your composition. So depending on your space budget, doing something simple like setting a panning position might push you over the limit. Since your songs are most likely going to be played in a loud auditorium, consider if it's really necessary to spend your bytes on subtle mixing choices.
I'm also of the opinion that giving more space to the code is usually better. So anything you can do that buys your coder space is a plus. If there's space left over, it's usually easier for you as the musician to fill it up.
I'm also of the opinion that giving more space to the code is usually better. So anything you can do that buys your coder space is a plus. If there's space left over, it's usually easier for you as the musician to fill it up.
Basically, you have to be mindful of all these items and all the restrictions for pretty much every note you put down. They either make it so your song won't play, or they increase the size of your music in the final production.
As a sort of trade-off, Clinkster is extra helpful though. It offers a folder called "easy_exe" you can drop your song in (if it's named the right thing) and a utility to run that does the compile and compress steps for you to give you ballpark idea of how big your music is. The compilation step also tries to check your song to make sure you aren't violating any of the restrictions. This can be frustrating at first, until you get used to disciplining yourself within the environment. I recommend writing a pattern or two, and running the easy_exe process on your song to see if you're doing something wrong. I made the mistake of not doing that early on and spent a couple days going through my song and removing things that didn't work.
Also, in my case, I didn't have a lot of control over the compose portion of the process. I had the Second Reality soundtrack that I had to try to reproduce and that was that. In the beginning, I figured I'd go for as close of a 1:1 conversion as possible and try to figure out cuts later. It turns out this was harder than I anticipated.
No comments:
Post a Comment