Search options (Page 4 of 40)

Ha, I missed that gem

I dunno either, you could very well be right and it just doesn't exist. It's just what I'm guessing based on various factors:
- music was commmonplace on mainframes
- the same music techniques re-emerged quickly when Altair & friends became available
- documentation on minicomputers is notoriously hard to find, much worse than finding things from the mainframe era
So since the novelty had worn off by then, perhaps it wasn't considered to be note-worthy. Even on mainframes music is often remembered in this kind of hand-wavy manner of: Oh yeah, we also did that, but then, so did everybody else...

You could very well be right about the business environment not exactly encouraging tinkering. Back in 50s and 60s the whole music thing apparantly had some business value in terms of promoting computers, but in the minicomputer era that no longer applies, of course. Then again, aren't a lot of people bored at the workplace? I'm sure there must have been at least some degree of off-the-record activities on these machines...

The Philadelphia record I know, but what's Classical Mosquito? A quick search didn't really turn up anything that seemed related.

A huge leap forward! The spectrum of sounds coming out of this thing is amazing. Congratulations Shiru, this is a real masterpiece.

I noticed a slight inconsistency between how an instrument sounds from the instrument view's PlayRow and how it sounds in the main editor, under certain circumstances. See the attached file. I guess the actual problem here is that Rest does not work with this instrument, but I like the sound that's leaking. It's possibe to force a rest by setting another instrument at the rest note. So it would actually be nice to keep the "feature", but somehow making sure it sounds the same in the preview.

Wahoo, now you're on a roll!

Excuse me for having a brain freeze right now, but what is the purpose of the rla in normal phasing mode?

Some tangentially related, inspirational reading: Grayscale on 1-bit LCDs. Would be interesting to try and apply some of the more advanced techniques to 1-bit music. Iirc perevalovds was using error diffusion of sorts for 1-bit sampling.

Yep, I'm using Print, and it's called twice here. Ehhh... well, it's not causing any major issue, so I'd say let's just walk away from this one.

Also found the bug that causes peskysoundzx to segfault. It seems that Angelscript does not like implicit type conversions in conditionals. The following changes to peskysoundzx.1te will fix the problem:

line 542:

    if(row<int(songLoopStart))//start before loop

line 549:

    if(row<int(songLoopEnd))//start inside loop

line 748:

    if(takeLoop==1) if(row>=int(songLoopEnd)) row=int(songLoopStart);

Spent some time trying to tackle the notorious "Z80Ass error: label already defined!" error again. I still don't know what exactly is going wrong here. The .loop label is indeed set twice under some circumstances (at the start of a block, in any case). So for esex, it will output this:

.song
.loop
    db #68,#00,#82,#e4,#82,#e4
.loop
    db #01,#01,#01
    db #00
    dw .loop

Anyway, I found a possible fix. In the affected engines, you usually have something like this near the beginning of the Compile function:

    row=startRow;
    takeLoop=0;

    if(oneShot==1)
    {
        len=1;
    }
    else
    {
        len=songLength-row;
        loopRow=-1;

        ...

Initializing loopRow to -1 before the conditional instead (so it affects both branches) prevents the error from occuring. Not sure if it causes any problems further down the line. I haven't noticed any yet.

Btw it seems the assembler always runs twice. Is this intentional?

Whoa, a wild garvalf appears! Good to see you're still around, mate.

Btw, I think I know what you mean re: maths now. It's often kinda tricky to know what the resulting perceived tonal frequency will be.

I think that generally, pre-calc is a viable option. The number of unique notes in a song is usually not that high, so size-wise it's probably ok. More broadly speaking, pre-calc could open up quite a few new paths for beeper. We'd just need an editor that supports that *cough cough*

The alternative would be to, well, use a suitable modulator, which boils down to having one or more additional counters/oscs. Which is what lead me to the "scheduler" design I described above. The whole scheduling part is actually not that important. The core idea is to unroll the sound loop, say, 8 or 16 times, updating the main counters on each iteration and spreading out the more expensive computations across the various iterations. When using a 12-bit main counter, updating an auxilliary 8-bit counter every 16 sound loop iterations should give sufficient precision and speed.

My last, failed experiment uses something along those lines. It's running off 32 byte wavetables (which, in conjunction with an 8-bit main counter, gives a reasonable frequency range). When the aux counter overflows, a variable offset is added to the wavetable pointer, and the offset itself is negated. The problem is that my usual 16-32-64-112t PCM renderer is too noisy, so I would need to rewrite the whole thing using multi-core (ie, one copy of the sound loop for each volume level). It should be possible without duplicating all the "expensive calculation" versions of the sound loop, but eh... it's still a lot of tedious work.

Neat idea, don't think we've used that anywhere yet.

I wonder if it could be pushed even further. Like, instead of every frame, add the offset at a variable rate. That could perhaps turn into a sort of 1-bit FM, without the use of PCM emulation trickery. (Sorry for hijacking your idea immediately, but I recently tried to implement actual FM again, and came to the same conclusion as last time: It's possible to do the necessary calculations fast enough, but the output is too noisy for reasons not entirely clear to me.)