Search options (Page 5 of 21)

I was thinking more on the idea with references, and come to the same conclusion, it is better to have it as a manual 'sync' command rather than an automatic update. Besides of the possible unwanted changes, it brings too much trouble handing the insert/delete position (as all data shifts inside all blocks). I'm going to think some more before trying to implement it. At least a simple block copy function is possible and should not hurt anything, like, press something, input an existing block name, and it'll get copied into current position.

I implemented RowOpt to cram down all songs into my 1-bit collection, it worked just fine at the moment, but yes, it may have issues. One thing is that it won't optimize above the slowest speed, which is vary for different engines. I confirm the issue with the example, will look into it.

A minor update to v0.43:

- Main/side display in the header with M/S
- Rows with contents on the other track marked on the left with > < (depending on current track)
- Inactive track gets displayed in the dual mode (F6)
- Marker name copying for the whole-width copy/paste operations
- Module filename and path displayed in the window header

I also got an idea for another big improvement to the pattern-less system, a link for the already defined named blocks, but I'm still not exactly sure how to implement it interface-wise. It certainly would be a front-end side feature, so no changes needed for the engine scripts. Basically, we already have blocks of variable length and with an optional name. That name can be used as a reference for a 'link' that would synchronize contents of the same-sized same-named blocks. So you would be able to edit one block, and it automatically updates all linked blocks.

Edit: actually when I was explaining my idea here, I got a better understanding how to do it. Hopefully it won't turn the tracker into another hard-to-fix glitch fest.

This was a matter of discussion for several years on ZX scene, and the conclusion was that the difference between these volume levels is very subtle (a fraction of a volt) to be noticed by the ear; and this behavior is not replicated on most Amstrad models and clones. To my knowledge, no one ever actually tried it, though.

Yes, this exact idea. Although I never seen this one, the one I saw was using Video RCA connector plugged into Audio input. Anyways, very cool stuff.

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.