Search options (Page 6 of 21)

The whole thing about XM format is that it is just a convenient enough container that is easy to parse and convert into any custom format with strict channel management, and it allows to approximate the resulting sound while composing to some extent. So it is a easy way to set up a rudimentary but working tool chain to compose music for a custom sound system before taking a long mile of making custom trackers and stuff like that. Other than that, original purpose of the XM format is irrelevant here, i.e. it is not about playing actual XM files made to be played with regular XM players.

The same could be done with MIDI, but it is just way less convenient. The MIDI format is more difficult to parse, it does not feature a pattern format (which is the go to memory saving technique), the channel management is not strict, as each MIDI channel is polyphonic, and it takes more effort to make the composing tool to produce some sound that would be similar to the end result, to hear the approximation of the end result before finishing the song.

The sound approximation is important for chiptune musicians, as they rely on the tiniest details of their music arrangements to make it sound as impressive as possible within given limitations. Something as basic as a single channel rendition of Ragtime does not really need this.

You task in general looks much like something that creators of a simplistic Arduino sound routine would do - they're usually making a converter from a single voice MIDI into their custom sound format. So maybe google for articles on this, and you may find some converter code that would be relatively easy to adapt for your purpose.

So the tempo issue in the ESEX seems to boil down to just line 1340, replace it with

wait_acc-=drum_frames*4;

Tempo seems to be stable now.

I also changed the front end logic to use default engine speed on engine change by F7. Preparing a minor update, just need to figure out that keyboard thing.

Fixed some minor and not so minor things there, the download link is the same.

One of issues was a bug in the percussion emulation that made the 'cut' settings to not work properly. Another one was the usual thing with non-latin characters in the file paths. Finally got this figured out how to deal with it within SDL and a multiplatform app, so it'll be fixed in 1tracker too.

Prepared a more informed overview of the cards capabilities.

Very good points. Yeah, indeed, an external third party cross assembler does not solve the problem in a long run, and I really don't like to go to licenses other than WTFPL/CC0/CC-BY for my open projects (the MuzCell tracker uses a GPL 8253 core, thinking to replace it with my own basic implementation before release to avoid GPL'ing the whole thing). Custom multi-target assembler implemented on the front-end side and an ability to still use the script-implemented assemblers at will (how it works now) is probably the best way to go.

I agree, a new approach to the tracking is one of key features of the 1tracker, not adopted anywhere else at the moment, but ultimately proven to be viable, so better to stick to it. The CALL idea I think is another key element that may make the concept even more solid.

Either way, it is possible both to implement patterns in the front-end without reworking the engines (just dumping the song as one single pattern), and to implement order-less front-end that will cut the song into patterns for a pattern-based player. Some engines in 1tracker actually cutting the song into small patterns (Huby), and I kept the order list support intact in most of your engines too, just dumping the song into a single long pattern.

Thanks! The tracker is getting along, the main editing features are all there (no instrument editor yet), player architecture is coming together, it just started to make some sounds via crude emulation. Once I'll get the basics to work via SDL build and DosBox emulation, I'll move to the real thing on a MS-DOS rig to explore the actual sound possibilities.

At the moment I'm thinking to just drive all the control bits with software envelopes to begin with, to get most flexibility, then experiment with instruments, and maybe remove envelopes that aren't much useful.

Yeah, can't see anything special there.

AngelScript's error messages can be kinda irritating at times, especially the 'out of bounds' ones for arrays. Like, no mention which array access caused it, so go make a guess if it happens (quite often).

Yeah, and there is not enough personal time to those who are still up to make music. I myself have a mile long list of plans for music releases, albums and such (beeper, chiptune, synth, and so on), and some are waiting there for a decade by now. Making software is kinda less time consuming than making music to me, because at least I know the exact goals to achieve. With music it takes lots of experiments and sketches, and involves getting into a specific mood.

Actually that's one of reasons why I'm always returning to improve the software and to inventing more engines - I'm seeking the ways to balance out the amount of routine and creative effort needed to make music. 1-bit stuff is very appealing in this regard, because you have only so many sound possibilities within a particular engine, and it gets more about music than about fine tuning every single knob on a synth of 1000 knobs.

v0.4 is here!

In general it was expanded a bit to adopt the numerous sample-driven engines. Script API updated, but it is a bit incompatible with the previous one. A capability to save files from script has been included, as well as capability to have a few different file dialogs within a script.

Envelope and text input editors has been improved. Now they're allow to edit envelopes and strings that are wider than the screen, and there are extra controls and visuals for more convenient navigation.

A built-in engine docs viewer in the Info tab (F6). Audio file export (Ctrl+F8).

WAV file import script updated to support files with extra info chunks (like ProTools exported, lots of garbage in these).

Ear Shaver and wtbeep engines has been updated. Ear Shaver EX, qaop, yawp, PhaserX, rawp, fluidcore, PeskySoundZX, Archie engines has been added.

Got it supported in 1tracker. Sounds very clean and nice, indeed, which is pretty impressive for a 5 channel engine.