Alright, I see you point. To be honest, I´m all in for a new batch of Scannerboy´s sync interface considering it´s capabilities to sync so many other gear that doesn´t use midi. Just trying to find a midi sync solution until or if he will ever do a new batch. *fingers crossed* . How many were made in the first batch?

Last edited by clickclack777 (March 6, 2017 7:59 pm)

Its really cool to hear that a new batch *might* happen!! Does anyone know how things are going?
Speaking of the software itself, defMON, did it die out or will there one day be a new version? (I have read both "No", and "Maybe" on various places on the web). I tried to register on the wiki by the way, but the defMON-wiki pw did not land in my inbox.

Last edited by COVOXED (March 17, 2017 1:02 am)

defMON isn't actively developed, but I wouldn't necessarily say that it is dead. You may still see occasional bug fixes and possibly still some additions of features though I don't make promises.

See PM about the wiki registration.

I hear the Alien Group Voice Box speech synthesis update is on the way smile

Hey, I just want to clear things up.
Im currently moving to another city so right now Im too busy to work on the adapters.
Maybe later this year when things calm down and there will be enough interest I can start working on a new batch.


Last edited by scannerboy (March 21, 2017 9:59 am)

Okay. I decided to share mini-bug report on several defMON builds. I'd really appreciate to get some feedback.

20090304 build

1) If you load saved tune from the disk each new (unused) pattern will be missing end-pattern signature (red dots) at the end of the pattern. Unfortunately you're unable to put it manually in the last line again (you can put it anywhere else but not on the last line). This leads to player bugging out on pattern changes.

2) It's impossible to copy+paste patterns on tunes loaded from the disk anymore.

20141107 build

1) You can fix missing end-pattern signature (red dots) bug on corrupted tunes in this build.

2) If you load saved tune from the disk you still won't be able to copy+paste patterns anymore.


Question 1 - If there's any workaround copy+paste not working after loading saved tune in 20141107 build - please let me know.
Question 2 - If there's any workaround missing end-pattern signature in 20090304 build after loading saved tune - please let me know.

Last edited by F7sus4 (June 4, 2017 12:05 pm)


Not sure why one would use such an old version as 20090304 (8 years ago) at all? In general it is advisable to always use the latest build.

Regarding the pattern end-marks, I've noticed this bug from time to time as well. However, it very rarely happens to me myself, whereas for some ppl it seems to happen more often. This bug really confuses me and I'd be happy to get more detailed information that could help track down when it actually happens. The way you describe it here, you seem to imply that it *always* happens to you? Is that really true?

About copy+paste after loading/saving tune, I haven't experienced that myself. Again I'd be happy to get more detailed information on when this might happen. It sounds like something that could be related to the first bug, e.g. that the copy/paste routine freaks out when no pattern end-mark is encountered.

I sometimes use 20090304 instead of 20141107 simply for downwards-compatibility (e.g. TR+AF behaves differently in 20130803 and newer builds etc.) and because we had dualSID support cut out in the public 20130803 version at that time.

Notice 1 - the lack of end-pattern marker (red dots) bug always coexists with no copy+paste pattern bug (shift+N = the screen flashes red but nothing happens). I guess they are connected somehow (defMON not being able to recognize start+end of the pattern to copy because of missing end-pattern marker?).

Notice 2 - the bug will never happen if you start a new tune. It always happens after you load a tune from a disk. It looks like the end-pattern marker is not written to unused patterns. And after loading a tune from the disk it's simply not there because defMON doesn't automatically fill end-pattern markers into unused patterns.

To reliably reproduce it: 1) Start editing any tune. 2) Save it to disk. 3) (optional) Restart your C64. 4) Load the tune from the disk. 5) Voila.
No red-dot markers in any new pattern. And no copy+paste possible.

A quick video:

Solution I tried:
I hoped that in both 20090304 and 20141107 it would be possible to work around the bug by copy+pasting existing empty pattern (00) with the end-pattern marker into new pattern that became corrupted (force override). That would be easy solution but when the bug happens - copy+paste doesn't work at all either (the border flashes red color only but the pattern is not copied - like at the end of the vid).

It happens both on real C64 (15+ different mobos+chips tested dating from 1982 up to 1993) and in emulated environment (Vice/CCS64/whatever).

I hope it helps and I'll be happy to provide more feedback when necessary. Apart from this minor issue, no other C64 music editor ever provided so much freedom and versatility as defMON. :-)

Last edited by F7sus4 (June 5, 2017 9:23 am)

Wow. smile Now that is clearly the most detailed and thorough bug report that I have ever received in relation to defMON. It certainly helps. Thanks for that! smile I'll try to look into it as soon as possible. The next version will also include some small bugfixes related to stereo SID stuff.

Also good to hear that you enjoy using defMON.

Speaking of future improvements, if there are any planned, I'd again sell my soul to have the possibility to change x1/x2/x4/x8 raster-speed on pattern via command. :-)

Last edited by F7sus4 (June 5, 2017 10:48 am)

Hi! I managed to track down the bug now thanks to your report. Not sure exactly when I will have the time to actually fix it, but at least it is within reach now. I won't do any promises here, but hopefully I'll fix it within a week or something.

A command to change the multispeed setting is — unfortunately — not very likely to be included since the multispeed stuff is actually handled by the editor (e.g. by the code that calls the player code) rather than the player code itself. Therefore such tunes wouldn't work when played outside the editor, e.g. after packing them. It is a reasonable request though and of course I see that it could be useful in some ways if it would have been implemented.