Search options (Page 5 of 20)

Oh, actually you're reminded me one interesting topic. I recall someone already attempted it, but generally it is totally underexplored, I believe. The idea is to generate audio using the video output. Like, we often put colored strips to the screen when a beeper engine is working (because Spectrum shares border color selection with the sound output bit). These strips actually produce voltage changes in the video signal at audible frequencies. It is possible to display patterns on the screen that will produce certain tones, and by changing the patterns it is possible to play music.

Hehe, guys, this does not work like this. I'm not sitting on a pile of finished GTIA songs ready to be sent anytime, it had to be made from scratch just before the deadline. So not this time... Nevermind, I'm actually just made one, sent it already. Don't know if it'll make to the compo, but let's hope. It sounds a bit glitchy compared to the ZX version, but as usual, there is no time to figure out what is wrong (kind of a sound port contention?). Party version it is!

Somehow forgot to make this small update. v0.41:

- Minor fix in the color schemes, c64 got brighter
- dirent updated, utf8 file paths supported
- Minor tweaks to the file selection dialog layout, navigation arrows added
- The global speed now resets to a default of the selected engine on an engine change
- MML-style envelope parser in engines now also support L as | and X as * to make it usable with QWERTZ keyboards
- Other minor fixes

Unfortunately the problem with QWERTZ keyboards in SDL isn't one that is easy to fix, so for now there is that workaround with L and X. Hope it'll help to make the engines usable, at least.

They do have a MOD to custom format converter, it does the resample and applying of all volumes, creating all sample data automatically. The trick is to compose the song within the MOD container, as it is really, really limited. Remember, 15-31 instruments, all patterns are 64 rows long. There is no priority system in use, i.e. the MOD had to be actually composed as 1-channel.

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.