Search options (Page 8 of 13)

About the "-1" step: That is because defMON is designed to implement as little "built in" functions as possible. Things like hardrestart, vibrato, etc.. Instead it is up to the user to do it themselves in the sidtab. That comes at a cost of course (less automation), but the benefit is increased flexibility. You can do any kind of hardrestart in defMON, whereas most other editors only feature one type of built in hardrestart and no reasonable way to do it manually (especially not at that first step in the sequence).

Also, implementing hardrestart without that "prior first step" in sequences requires that the sequence parsing code looks ahead: e.g. that it parses sequences before it is actually time to parse them, to see if a hardrestart sound is coming up, because the hardrestart has to be trigged 2-3 frames (depending on what sort of hardrestart you do) before the actual start of the audible sound. Such look ahead-parsing adds overhead to the code and consumes CPU that isn't strictly required. Original defMON was intended to be usable in demos/games, with low raster time consumption.

if defMON II becomes reality at some point, it will ditch the idea of its tunes being usable in demos/games, and rather go for usability and allow the program to use all the CPU power there is. If that happens, the weird "-1" step won't be there, and things will rather look like the rest of the trackers in this world do.

Have a look here for a BPM calculator, which may make manual syncinc easier:
http://toolsforscholars.com/defmon/bpm.html

There are no plans for adding the flashing thing again.

Thanks for reporting! Yes, this is the right place. Actually the same thing happened to me as well for the first time only a few days ago. Haven't seen it before, or actually even heard about it from others either. Will keep an eye out for that. Any clues of under what circumstances this may happen are of course very welcome. Anyway, since it happened to me for the first time only recently, I kind of guessed that this may be some new bug introduced in recent versions, but maybe it is actually an old bug then. Good to know!

On the whole I can't recommend the G*P version since a bunch of bugs have been fixed since then, but I guess you know that already.

Trick to apply speed settings globally:

1. CTRL+Z CTRL+A to select "ZONE ALL" = edit all sequences at the same time (warning! This mode of editing is obviously potentially very destructive in case you happen to change something else as well. The border color will change to indicate that you're in a different mode than the normal one.)

2. Then type in the speed pattern you want

3. CTRL+RETURN to get out of this mode and edit normally again. (The border color will go back to normal.)

Then again, doing it the way you do isn't necessarily a bad solution either. I also do that a lot.

On my wish list would be full MIDI out, and also full MIDI in... ...but that would be more than a mere revision of "the same thing" of course. Just saying.

ADSR in brief:

Attack
$0 is quickest and $f is slowest = the time it takes for the volume to rise from zero to max. The Attack phase starts whenever the GATE bit is turned on (more info on the GATE bit below).

Decay
$0 is quickest and $f is slowest = the time it takes for the volume to fall from max and down to the Sustain level (see below). The Decay phase starts automatically as soon as the Attack phase has finished.

Sustain
$0 is silence and $if is the loudest = the VOLUME (not the time) that the ADSR envelope stops at after having gone through the Attack and the Decay phase. As long as the GATE bit is still on, the ADSR envelope will stay in the Sustain phase forever. When GATE is turned off, the Sustain phase ends and the Release phase (see below) starts instead.

Release
$0 is quickest and $f is slowest = the time it takes for the volume to fall from the Sustain level and down to zero volume. More accurately, the Release phase may be started even before the ADSR envelope has reached the Sustain phase. For example, if you have a really slow Attack, and turn gate off before the Attack is done, the Release will start falling from whatever volume the ADSR is at, rather than from the specified Sustain level.

The GATE bit, that triggers the ADSR, is found in the WG columns on the sidtab screen in defMON. Normal usage of the WG columns would be to only use the upper nibble (e.g. the X in $XY) in the first WG column to set waveforms, and to only use the lower nibble (e.g. the Y in $XY)  in the second WG column.

So to set triangle waveform (the $10 in the first WG column), and the gate bit to ON (the $01 in the second WG column), and ADSR to $11fa, you execute a line that looks like this:

WG WG AD SR
10 01 11 fa

...and then some time later you would execute a line where there is a 00 in the second WG column to turn the GATE bit off again, which will then have the effect that the ADSR envelope stops hovering at the Sustain level and instead enters the Release phase. Like this:

WG WG AD SR
.. 00 .. ..

(This is also why there are two WG columns, because it allows the waveform to be "remembered" (in the first WG column) even if you turn the gate bit off in the second WG column.)

This explanation is quite technical, but hopefully it helps in some way at least. In those instruction videos that I'll do, I'll make sure to visualize the ADSR stuff graphically, to make it easier to grasp.

Nice! I'll do my videos in any case, but more is always better for these things. Actually I did some preparations for this yesterday, so I think I'm rolling now, so to speak.

For quite a while I've been thinking about making a series of instruction videos on youtube or something, possibly even two: One about how the SID works in general, and one about how to use defMON. Main obstacle is actually that I don't have a video camera.

The finetune/slide stuff is actually just a continuation of the frequency table so all you would have to do is to calculate some more data. Except the twelve bytes following the _player_notes_lo_slide label are just some sort of manually typed in interpolation between 0 and $11 (e.g. the first byte following the _player_notes_lo_finetune label). Only every second byte are used on that row, so that's why there are pairs of identical values on that row. If you don't use slow slides (less than $86 in the sid table or so), you don't need to bother about those 12 bytes of slide stuff.

So, what you have to do is bascially to calculate 12 octaves of NTSC frequency data, and put the lobytes in one table, the hibytes in another (I'm pretty sure it is the same in GT, except for maybe a different number of octaves required), and then make that manual interpolation between 0 and X for the slide values if desired.