I appreciate the syncing link. It made my day waaaaay easier. big_smile

I also do understand the reason for position -1 being there as I think I guessed properly ADSR hardrestart being the most possible scenario. It makes sense.

However! big_smile In some cases this limits the flexibility instead of increasing it. Again, ADSR hardrestart can be done without using -1 position. And if you use every single line of the pattern for notes, you will find yourself forced to make multiple copies of the next following pattern only to move the last note from previous pattern there.

Last edited by Amelinium (Feb 22, 2018 2:54 pm)

There are in fact a number of complications associated with doing hardrestart without using a -1 position (unless you have the kind of look-ahead code that other editors have, but that I wanted to avoid for the reasons that I mentioned). Some of these complications relate to mixing sounds with different kinds of hardrestart or no hard restart, and some of them relate to synching defMON to external synths.

Anyway, none of this really matters too much because: note that you can actually use the -1 step as a step 0. That is, you can indeed put your first note on that -1 step. It is actually just a way of presenting things graphically that makes you think the "-1" step is a -1 step in the first place. You could just as well treat it as step 0 and do hardrestart the way you want to (e.g. to make the actual start of the audible sound a bit delayed compared to the position in the sequence where you put the sidtab value, if I understand you correctly.) When you press F1 or F3 to play your tune, the -1 step will be played first, so in that sense this step is actually just like any other "first step in a sequence". It is just that line numbers will seem odd in that case of course, but at least the choice is there.

Shortcut to get to the -1 step in a sequence: Press CTRL+G twice. First time will take you to step 0. Second time will take you to step -1.

@Frantic: Would it be possible to improve "instrument table" in the next defMON version? I specifically mean JP (jump) with predefined amount of loops (similar to how FF xx 02 works in pattern list = loops jumping to xx for 2 times). At this moment it's quite easy to run out of lines when creating longer volume or filter envelopes. This loop would be the ultimate help.

Last edited by Amelinium (Aug 4, 2018 11:44 am)

Although it can get messy, it's perfectly possible to do these kinds of longer events in the sequences instead.
An advantage of that is also that you get encouraged to make the sounds more dynamic, instead of having static instruments.

I'd say that the possibility to not even have any fixed instruments at all, is what gives defMON its spiritual power.

Guys, please don't get me wrong. My decision to stick with defMON was to have absolute control over the sound. Having a bit of predefinied automation is still different than editor doing all the magic instead of you. I hope you get my point. I won't argue if it's easier to program loopable JP in instrument table or to type everything manually via pattern, although I'd actually argue it will fuck up the envelopes without $09 testbit hardrestart each time you retrigger it without closing the gate.

Amelinium wrote:

it will fuck up the envelopes without $09 testbit hardrestart each time you retrigger it without closing the gate.

The testbit has nothing to do with ADSR envelopes and gate on/off. What the testbit does is to reset the oscillator that produces the waveform, and that is completely independent of the volume envelope generation (ADSR + gate) in the SID hardware.

Anyway, I can see the point in some automation like the one you're thinking of, and of course I've thought about it too, but it won't happen because:

There are a lot of things that would be nice to have and that would make a lot of sense — individually — but starting to implement them, one by one, will gradually make defMON slower, more bloated, probably more prone to bugs due to increased complexity, and so forth. The limit has to be drawn somewhere, and I've chosen to draw it pretty narrowly around what's really important to have. Think of it as a design decision.

A change like this would also break the file format of defMON tunes, and this would cause some trouble for various secret tools that are around.

frantic wrote:

There are a lot of things that would be nice to have and that would make a lot of sense — individually — but starting to implement them, one by one, will gradually make defMON slower, more bloated, probably more prone to bugs due to increased complexity, and so forth.

It's always a matter of choice what is a burden and what is actually useful. smile

Last edited by Amelinium (Aug 16, 2018 1:30 pm)

Just wanted to report the large file bug again. Can't tell what it causes but happens more often than in previous builds... Using 20171026. sad

Thanks for reporting!

Have other people experienced this as well? It has happened to me once.