1

(17 replies, posted in Trading Post)

Good to see that people keep building the sync adapters. I can confirm that I am not aware of anyone else building these at the moment. Props for doing it!

Best wishes,
Frantic

2

(438 replies, posted in Commodore Computers)

Nice work! Don't hesitate to add such useful contents to the defMON wiki. Send me a message on here in case you want me to create username/password for you to the wiki. (The only thing I would need to do that is your email.)

Not sure but could it be a PAL vs NTSC issue?

4

(438 replies, posted in Commodore Computers)

[apparently this was sent twice to the server. this message can be deleted]

5

(438 replies, posted in Commodore Computers)

Hi guys,

Sorry to say, but defMON will no longer be a public project. I started coding defMON about 15 years ago, and it has been public for the last 8 years or so. The reason for pulling the plug is that I am receiving various accusations, and since 25 of April even some vague threats. I have definitely had enough. Therefore I am now closing the doors on this project. At the moment I can't see that there will be any development behind closed doors either, as these things really made me lose inspiration for this project altogether. Of course things might change at some point, but I can't see that it will happen within the foreseeable future. Sorry, but that's how it is.

I won't delete the defMON wiki or any of the old downloadable versions though, so that will still be available. People here have been helpful in finding various bugs, and while many of them have been fixed, not all of them have, but I would still say that the current version seem to be relatively bug free. At least that is my impression. (The reason for why some of those bugs are not fixed is precisely because it has been hard/rare to even make them appear.) Hence, people who want to give defMON a try should be good to go with the versions that are already available. More specifically, the latest version is the recommended one.

As for this forum thread, I am not going to read/write in it anymore, which means that it will no longer serve as a place for bug reports.

That's all I had to say. Take care out there!

Ciao!

6

(17 replies, posted in Trading Post)

Cool! I'd be happy to test it, but I live in Sweden.

I'm the author of defMON though, so perhaps that could help in case some bug fixing would turn out to be needed.

What is needed to reflash? Usb-c cable and the arduino IDE, or something else?

7

(438 replies, posted in Commodore Computers)

@Martin: Nice! big_smile Unfortunately it is no easy task to shrink the characters in the font to 4x8 size, instead of 8x8. The reason is that the graphics chip of the C64 has this "character mode" which is used in defMON, where it operates with 8x8 chunks of graphics. If one would use 4x8 characters, then one would have to do plotting of individual pixels to draw the characters instead, which would be way too slow for the processor to handle.

Another problem is that 1 pixel wide graphics on the C64 do not work well on many monitors. In some cases it can turn out barely visible on an old PAL TV. That is the reason for those "two pixel wide" fonts.

I have actually been experimenting with a custom font that shrinks the "C-3", "D#5" etc character strings to something that fits into two 8x8 chars instead of three, so some things like that are possible to do and still use the "character mode". The problem is that custom fonts have to be put in RAM, so some RAM is wasted on that. If one uses the built in font of the C64, there is no need to "waste" precious RAM on a custom font as the system font is located in a separate ROM chip. So, that is a trade off between different priorities.

Having said that, I must confess that I lost some of the inspiration for a defMON II after the conflicts raving around here and on other forums a while ago. What I am considering instead though is something like a "defMON 1.5", which builds mostly on the good old defMON, but that does some changes that might break backwards compatibility of the tunes. (defMON 2 would do that  too anyway). I haven't decided though, so at the moment this is just something that I have been thinking about. Primarily it would be a matter of investigating how much support for a midi interface ( https://github.com/anarkiwi/vessel ) I could add to defMON. Things like MIDI sync IN, MIDI note data OUT and so on.

You can use the sidfx already in the original defMON. I have that in two of my machines and it works fine with defMON.

8

(438 replies, posted in Commodore Computers)

Thanks for reporting! Sometimes I wish I never would have forced 2sid support into defMON. I'd say about 95% of all bugs I have fixed in defMON over the years were related to that, directly or indirectly. smile

Even better would of course have been if defMON was designed with 2sid support in mind from start, but that's another issue.

Thanks a lot for the bug report!

I would say: Focus on learning the actual software, and then look at tunes made by others in that software.

10

(438 replies, posted in Commodore Computers)

The defMON wiki has a new home:

https://www.vandervecken.com/defmon/

I am indebted to Anarkiwi for his generous sharing of web space.

11

(438 replies, posted in Commodore Computers)

F7sus4 wrote:

This is what I was thinking when I started to use defMON, and I believe there was some other person commenting it here in the topic as well, but after a few years - I'd strongly defend this solution.

Hehe.. Yeah.. I actually agree. It is funny how one thing (e.g. insistence of doing hard restart manually since that lead to more generic code in the player without special code for hard restart) led to another ("extra" step in the beginning of sequences) and how that turned out to be a quite useful feature for some things.

I also seem to remember that someone commented on this at some point in this thread and I think I said then that in a way this is actually just a result of how the sequence data is presented on the screen (and... well... where you end up if you press CTRL+G for example), since the row numbers start at the second step instead of starting at the first step. So.. if someone *badly* wants the first step to actually be the first step, they can simply treat it that way. Of course they will run into problems then, if they want to put hard restart sounds on the first row, but... at least they can. smile

12

(438 replies, posted in Commodore Computers)

F7sus4 wrote:

I greatly appreciate it works that way. It allows to play e.g. swinging drum section while the corresponding notes keep their regular rhythmic values, or simply to land some notes/instruments with absolute precision (rated 12/10, would buy again!). heart

Yeah, I kind of like it this way too — even in hindsight, after all these years — but I think one drawback is this:

Swing-speed stuff can get a bit messy from a user interface point of view when combined with the fact that hard-restart instruments has to be trigged one line before the one where it is supposed to be heard. Strictly speaking, one could reasonably argue that this is not the fault of the way the speed column in the sequences works though, but rather a bad consequence of the way hard restart is handled in defMON. So, if anything, one would perhaps have desired a somewhat more user friendly way to trig hard restart stuff. (Like a setting that would configure whether each sound should be trigged exactly where it is put in the sequence, or +/- some ticks.) That would also get rid of the need for that strange "extra step in the beginning of sequences" feature of defMON, which is obviously quite weird. More like a necessary evil, given the way hard restart works, than a feature.

Oh well.. Too late to change stuff like that for the original defMON anyway. Worth thinking about in relation to a defMON sequel though.

13

(438 replies, posted in Commodore Computers)

So there was a slight difference after all in how the hardware worked. smile Thanks for this. I will send you a PM.

14

(438 replies, posted in Commodore Computers)

@martin: Yes, having a speed column built into each track is not an obvious design choice. When I made defMON I tried to opt for the solutions that gave the most flexibility, even if they sometimes resulted in solutions that require some more work on behalf of the user. In some cases that makes defMON outright odd, yes. smile

You can actually use different speeds in each channel, but they will always do sequence break at the same time. So, if one channel breaks earlier than the others, these other channels will also advance to the next sequence in the sequence list even if there was not yet any sequence breaks encountered in those channels.

15

(438 replies, posted in Commodore Computers)

defMON uses CIA timing. The "ticks" that were mentioned here doesn't relate to that, though. That just means the number of times the player code needs to be called to advance one step in the sequence.

So.. there are two factors involved in "speed".

1. The number of player code calls before advancing one step further in the sequence. In defMON the "speed" column in the sequence specifies the number of ticks until next step in the sequence, BUT... it is somewhat non-intuitive. (There is a reason for it actually, but..)  Writing "2" in the speed column actually results in 3 ticks per step. Writing "3" results in 4, and so forth. So the actual number of ticks is always one more (+1) than what is written in the speed column.

2. The time between each call to the player code. This can be controlled with VBLANK interrupt (on C64 it would be called a raster interrupt) or with a CIA timer. CIA timers are much more fine-grained, just like you say.

16

(438 replies, posted in Commodore Computers)

Hehe.. yeah that was kind of funny actually: that they work exactly the same.

Having the 1.8 version with that code in it could potentially be useful, yes. If you do it, i'd like to have it, and in any case it could be relevant to have the 1.7 version that you had already modified