Search options (Page 5 of 13)

A question of clarification here. What does "large chunks of instrument data" refer to here? Like.. just deleting a few rows, or... something like changing the block size and keeping SHIFT+RETURN pressed to delete like most of the instrument data? And also, what is it that gets corrupted? Is it the sidtab data specifically that gets corrupted (how? some random data shows up?), or does it seem to corrupt other data (like sequence data or whatever)?

Please respond at the new defMON forum, in this thread:
https://toolsforscholars.com/defmon/for … a7z2gc4rzc

The C64 video circuitry updates the image on the monitor 50 times each second = a frame rate of 50 Hz. Typically C64 music is played by calling the player code once every frame. The current compo at CSDb asks people to create tunes that call the player code half as often = 25 hz. This means that the sounds will have a lower "resolution" in the sense that SID parameters are only updated half as often as a normal single speed tune. You could think of it as the opposite of a tune with multi speed sounds in it.

("Tempo" is "how many times the player code needs to be called before a new step in the sequence is parsed", so that's a different concept. )

Yes, it will remember the patterns anyway.

The maximum number of patterns in defMON is 7F. All patterns 00-7F will be remembered the way you asked about here.

@f7sus4: Thanks for confirming. I just wanted to make really sure that there were no misunderstandings involved before going on extensive bug-hunts. I'm still unsure what may cause the bug though, so let me know if you (or anyone else) find some further clues about the context(s) where this problem may appear.

@d3ni$e: That's nice to hear. Thank you also very much for that second donation! You're the only one who donated any money so far, and I am very grateful for that. Regarding defMON tunes from me, I don't have any particular plans on spending time on anything C64-related at all except for that new editor. That will receive my full focus. All play and no work makes jack a dull boy.

Hmhm.. I wasn't able to replicate the problem. Staring at the code for a few minutes didn't reveal any obvious problems either. It looks pretty solid.

It is of course easy to mess things up when using SHIFT+U, even if the function works as intended, so just to make sure that everything is clear regarding its intended function: In this context "unused" doesn't refer to empty sequences, but to sequences that are not used anywhere in any of the two sequence lists. So if a particular sequence is only used in a single place and you press SHIFT+U at that location (so that sequence number no longer appears in any of the two sequence lists), then this sequence may very well be overwritten next time SHIFT+U is pressed at some other location in the sequence list. I guess you're both well aware that this is how the function works though. Just want to make sure we're on the same page.

So, if there is a bug here, any further information that could help track the bug down would be appreciated. This is definitely the type of function that should be rock solid. Messing up song data isn't fun. I have never experienced it myself though. Odd!

The amiga has the built in feature of looping sample waveforms. If you use a very short loop, you have a waveform there and it can be modified as you wish, since it is basically just a short sample. Editors like Future Composer, Soundmon and Sonic Arranger make heavy use of this as a central concept of how the player/editor works, and allows various forms of modulation of the looped waveforms — or Paul van der Valk's tunes in the Imploder tools. Hence these player routines sound very much like oscillators. It is basically the same idea as using the amiga hardware to loop short waveforms in Sound/Noise/Pro-tracker, but these other editors were designed with this type of usage in mind and therefore take it a few steps further.

Try plugging something else in, like your laptop, just to verify that the effect actually works. The output signal of guitars is very low indeed.

I haven't used the Ultimate64 personally, so I don't know much about it. As far as I have understood, the general idea should be that it should be fully compatible with the C64, but maybe it is more like 99% compatible in actual practice. However, in this case I guess it could also be the case that the Ultimate64 emulates a cartridge at the same time as you have the midi cart inserted. If so, there may be a conflict between the emulated cartridge and the MIDI cartridge. The DATEL cartridge uses the following addresses:

MIDIcontrol = $de04 ;write-only
MIDIstatus  = $de06 ;read-only
MIDI_Tx   = $de05   ;write-only
MIDI_Rx   = $de07   ;read-only

If the emulated cartridge interferes with this in some way, the MIDI cart won't work. Then you would either need to disable the emulated cart, or your would need to use a cartridge ROM that doesn't interfere (I think the Retro Replay ROM may be worth a try for example).

(Cartridges such as Final Cartridge, Action Replay, Retro Replay, and so forth generally also use the $dexx adress range. I seem to remember that I used a cartridge port expander at some point, to get a MIDI cart working at the same time as an action replay/retro replay cartrdige, and the cartridge port expander allowed me to shift the MIDI interface to the $dfxx range instead. Then I also had to modify the software I used so that it used the $dfxx adresses to communicate with the MIDI interface, instead of $dexx.)