Search options (Page 6 of 40)

I've been toying with a very promising new engine design that makes it possible to use computation-heavy effects, while also eliminating row transition noise. I don't have time to develop this into a full engine at the moment, but I thought I'd share the idea in case anybody else wants to play with it.

The design revolves around using a crude scheduler to implement basic multi-threading. Within every iteration of the sound loop, the scheduler allots a fixed portion of the available cpu time to the main thread, which updates frequency counters and calculates the output value(s) for the next iteration. The rest is allotted to a variable pool of secondary threads, which run consecutively in between each main thread run. In other words, our sound loop consists of two parts - the first part is always the same and runs all those updates that are required on each sound loop iteration. The second part runs varying tasks that do not require fast updates, for example counting length, computing some effect, or reading in note data.

The scheduler is implemented by pointing the stack pointer to the music data, and then simply RETurning after the main thread. To keep the music data size manageable, we need to implement sequence loops and subroutines as abstract operations running as secondary threads. Ideally we'd do nested subroutines, however that's a bit expensive to compute and in some cases one could probably get away without nesting. No nesting basically mirrors the sequence/pattern approach we normally use. The following example would play two notes over and over again:

sequence
    dw set_note_ch1, some_note
    dw init_loop, #3fe     ; set note length
    dw jump_sub, delay
    dw set_note_ch1, some_other_note
    dw init_loop, #3fe     ; set note length
    dw jump_sub, delay
    dw jump_seq, sequence

delay
    dw do_nothing
    dw loop, delay
    dw return

Now, that may seem like a rather inefficient way to just do

seq
    dw pattern
    dw seq_end
    dw seq

pattern
    dw length, note
    dw length, other_note
    db ptn_end

Perhaps it makes more sense to pick a certain number of threads, and think of the time they will take as your refresh rate/tick length, eg.

    ...
    dw set_note, note
    dw init_loop, #80         ; 0x80 * 0x10 + 3 = 0x803 loops/ca. 8 ticks (so we can get away with just an 8-bit length counter)
    dw jump_sub, fx01
    dw set_note, other_note
    dw init_loop, #40
    dw jump_sub, fx02
    ...

fx01
    dw calculate_expensive_fx_part1
    dw calculate_expensive_fx_part2
    dw do_something_else
    dw jump_sub, delay11
    dw loop, l1     ; 16 

fx02
    dw calculate_other_expensive_fx_part1
    dw calculate_other_expensive_fx_part2
    dw calculate_other_expensive_fx_part3
    dw calculate_other_expensive_fx_part4
    dw do_something_else
    dw jump_sub, delay9
    dw loop, l1

delay11
    dw do_nothing
    dw do_nothing
delay9
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw do_nothing
    dw return

Still expensive in terms of data size, but essentially we can now run things that we used to run in the outer sound loop (so, every 256*innter_loop_length t) at a much faster rate without affecting sound. This allows us to do stuff like fast&precise slides/vibrato and all sorts of variable-rate modulation effects. Also with recursive subroutines, you could actually have subroutines that generate subroutines... I think one could go pretty wild with this.

Hey, where'd the rest of the post go? Don't worry about being off-topic, there's no rule against OT on 1-bit forum, hehe.
In any case, that sounds lovely.

Yesss, I love these shed videos! The thought that there's someone on the complete opposite side of the planet listening to 1-bit sounds in a shed out in the countryside is just fantastic. If you don't mind asking, whereabouts in AU are you based?

I've heard about this machine before! Fat chance I'll ever see one here in good ol Europe though

ArcadeDB claims that sound emulation in MAME is "good", at least for the base 16k machine (though I've found that to not always be true for other machines), so it might well worth to give it a try. I've dabbled with MAME quite a bit, so If you were to upload a .tap or .dat or whatever the go-to emulator format is, I could try to work out how to load it.

Trying to get this to work, not sure what I'm doing wrong. I create a block, name it "intro", then move the cursor to a new position, type Ctrl+Q intro, nothing happens.

Btw I think it would be a good idea to move down the help page description for Ctrl-F to where the other block commands are explained. Also, for "copy or insert an existing block by typing in its name", you could omit the "in".

I'd need more information on this to make an informed judgement, but generally I think that's a terrain that needs to be treaded very carefully. With automatic updates, there's a risk that you'd accidentally destroy part of your work. Also, 1tracker's current copy/paste-centric approach has the advantage of encouraging variation. When I copy a section and later change some detail in one section, I'll usually apply the changes slightly differently in other copies of that section, often not even deliberately. Happy little accidents, to say it with Bob Ross. For me, it's one of the great strengths of 1tracker. I would possibly be more happy if the updates were manual, that is, you select a source block and one or more target blocks and then issue a command to sync them up.

Generally speaking, I've fully embraced the post-pattern age, haha. My latest pet peeve is actually something else - ticks. And I don't mean the ones that crawl around in the forest trying to kill you with a myriad of diseases. Yeah, those suck, too. Literally. Anyway. Having to deal with ticks aka row length aka speed is annoying. So you start to work on a melody or whatever. Now you want to add some ornaments, so you Ctrl-E that sucker a couple of times. Add yer ornaments, but now you want to save RAM so you optimize the rows. Now all your blocks have odd lengths and it becomes really hard to keep track of where the block borders should be when you move around stuff.

Leaving aside the implications of row transition noise, I think it boils down to this: You always want Speed 1 resolution (especially for 1- and 2-channel engines), but a) you don't want rows with no changes in your output data and b) you don't want all those rows cluttering your tracker view. a) can be solved by having the compiler collapse empty rows, so the big question is how to solve b). I haven't been able to come up with any good solutions yet, it's just something I keep thinking about.

Btw I believe 1tracker's RowOpt feature is wonky. The following:

Sp T
02 C-4
.. ...
.. ...
.. ...
03 D-4
.. ...
.. ...
.. ...
04 E-4

will be optimized to

04 C-4
04 ...
04 D-4
04 ...
04 E-4

which is obviously incorrect.

The problem is that a) MIC output is on average VERY quiet compared to EAR (-0.3V vs -5V and b) MIC output differs wildly across Speccy board revisions (let alone across models). So it's not that useful by itself, but I want to try and use MIC for reverb one day.

Edit: I tried it on my 48k (board rev 4B iirc), it was barely audible.

The Side track feature is fantastic! I didn't know that I wanted it, but now that I know what it is, I totally want it. 1tracker once again innovating the tracker space.

I don't fully understand this part. I know I can turn Side track playback on or off with Ctrl+F5, but what's the intended workflow to listen just to the Side Track? Mark the entire track and do Ctrl+T?

How would it be to have a possibility to somehow swap/copy/blend a section the current side buffer contents at an arbitrary position or even another track? I guess that would require some sort of visual representation of the Side tracks though. Perhaps have 3 display options: Side tracks off; show the all side tracks next to the Main track view; or show all side track columns next to their respective main track column. Side tracks would be shown in a different color, but otherwise act as regular tracks as far as editing is concerned.

Also since when has 1tracker had this RowOpt feature? Only noticed it now, that's great to have, too.

Still problems with peskysoundzx, on first run:

engines/peskysoundzx.1te (459, 1) : INFO : Compiling void Compile(uint, uint, uint, uint)
[1]    15724 segmentation fault  ./1tracker

Also the z80ass error persists, unfortunately.

Awesome tune Shiru, hyperactivity at it's best hehe. Too bad there weren't any more entries. You're welcome to blame me for that, too, though on the other hand you'd have steamrolled me with this one

Haha, I was watching the demo (the live yt version, hoping a proper recording will appear soon) and thinking: "Hmm, this music sounds really Shiru-like. But it can't be. I wonder who did it.". And then the credits rolled... Turned out great, really good interplay with the visuals.

I don't quite understand about the MOD end part. Wouldn't the best approach be to take the whole song and have the converter chop it up to create an optimal set of sample data? Or was there no time to build an "intelligent" converter for this?

I finally got around to listening to it, dammit. Fantastic little release! Serenity sounds like it could have been an intro for Space Beeps Love the arps galore on Mech Dance.