Search options (Page 4 of 13)

I see. Not sure, but that error message almost sounds like the overlap in RAM starts already from $1000...? If so, that would indicate that even a 1 byte long tune would overlap with "Bitmap_1" in this case. That is, it indicates that maybe there is something else going wrong here?

Anyway, the typical solution would be to use the graphics bank at $4000-$8000 instead of the default one at $0000-$4000 that you are currently using:
https://codebase64.org/doku.php?id=base … organizing

However, I should also mention that it *is* possible for me to shrink tunes a little bit further than the packer is able to do, like I said a few posts ago. Also, I am actually also able to relocate tunes. Relocating tunes means that I can move them elsewhere in RAM, so they don't have to start at $1000. I have done that for the "Rent a cop" games and in some other cases. It requires some manual work on my side, so it isn't something that I do on a regular basis. However, I'd say:

First try to use the other graphics bank, like I suggested, by setting $dd00 to another value and placing the graphics elsewhere in RAM. That should work in most situations and I really think it should probably work in your case too. If, for some reason, it isn't actually possible, I could have a go at shrinking and/or relocating the tune since you have paid for defMON. What I need then is the tune in worktune format, rather than a packed tune, and obviously it would also have to be the final version of the tune so I won't have to do it all over again.

Good to hear that you find codebase64.org useful by the way. I am actually the person who is in charge of that site.

Hi!

Most of the memory used by the packed tune is used by the player code, rather than the player data. This is why you see that it takes quite some size even if you make just a small tune. Also, 5 second tunes are rarely used, so in practice this is seldom that much of a drawback.

The player code in defMON is optimized for speed rather than size. There is always a trade-off. Either you write a player which is very small and takes little RAM, but then the code will also be slower, or you write a player which is very fast, but then the code will also be larger.

It would be possible to write another player (code) which takes much less space but which is also much slower, but that is able to play the very same music data. That could be desirable in some cases, but having more than one version of the player code often complicates things, so I have opted just to go for a single "one size fits all" player for defMON — and that one is optimized for speed, rather than size. Most C64 productions tend to prioritize speed optimization.

If you have a look at the table presented in the link below, you will see that the player code in defMON is among the fastest, compared to other editors. There are some editors that are substantially faster, but then it comes at the expense of limiting the features of the player quite a lot:
http://chordian.net/c64editors.htm

So the editors that you are comparing with are precisely those editors that haven't prioritized speed quite as much as I have done in defMON (or those that are both faster and smaller, because they offer less features). In the case of defMON optimization for speed (rather than RAM size) makes sense in yet another way, which is because it supports stereo sid and multispeed. When doing a stereo sid tune in 4x speed, having a speed optimized player is almost a requirement.

Having more then one player (e.g. one optimized for RAM size and another one optimized for CPU speed, and perhaps yet another one which is somewhere in between these other two) for the same editor also complicates things in the sense that the tune will sound sliiiightly different since the SID registers are written at slightly different times, depending on how fast the player code is that you are using. People tend to complain about that.

Did you ask out of curiosity, or because you are actually in a situation where you need a tune that is smaller than the one that the defMON packer has produced for you? Like, for something a one file demo where a lot of things has to fit in RAM at the same time, and so forth? For "special occasions" I can do some manual work on a packed tune, to pack it a bit further than the packer in defMON is able to do. This isn't something that is going to be implemented in the packer, precisely because it requires some manual work. That still won't make the playe code smaller though. It is just a matter of packing the music data a bit further. If you really need super small tunes, then defMON would probably simply be the wrong choice.

Here is a link to a tune that I created once, where the player code and the player code together only takes 256 ($100) bytes. That was clearly optimized for size though, and it (obviously) wasn't created by defMON:
https://codebase64.org/doku.php?id=base … une_player
https://deepsid.chordian.net/?file=/MUS … _Block.sid

...and another one which is also only 256 bytes:
https://deepsid.chordian.net/?file=/MUS … _bytes.sid

Ah, I'm afraid that's not quite what I meant. RAM is very limited, so recordings of such time-series of paddle data would quickly fill upp the RAM. The paddle support would be for playback only, rather than recording of envelopes.

What I meant was rather something like this:

* Values ("parameters") can be pushed into the buffer from particular positions in a sequence.
* Paddle movement can be set to affect values at particular positions in the buffer (at playback time).
* Sidtab lines can use (and set/slide/randomize/etc) such values in the buffer.

Example of usage: One particular line in the sidtab may set CP to the value which is currently stored at position 00 in the buffer. Then you could push different values directly from the sequence into position 00 in the buffer, to create filter sweeps directly from the sequence.

Another example: One particular line in the sidtab may set CP to the value which is currently stored at position 00 in the buffer.  Then you could use a paddle to affect the value at position 00 in the buffer, to make a paddle controlled filter sweep (at playback time).

Right. Yes, I've also used 1x/2x/4x/8x switching in live contexts as it is one of those few things that you can actually do in defMON that actually works a bit like applying an effect on the music, without having to go into specific bytes in the sidtab and modifying them to change the way things sound. I agree that the effect of doing this can sound quite interesting, although it also sound crappy in some cases.

On the other hand, there has also been many times when I wanted to change the speed of the music without changing the way the sounds sound, and that was impossible since the speed of sequence parsing was tied to the speed of sidtab parsing.

Anyway, defMON2 will be constructed in ways that are more compatible with the way that MIDI works. So, for example, if the C64 is to act as a MIDI slave, it makes more sense not to "drive" the sound parsing code in ways that depend on the speed of the MIDI clock, since that may vary and the user will then expect that only the sequence parsing should be affected if changing the BPM of the music in a DAW or so. ...and so on. In general, a lot of things become much more complicated when involving MIDI more fundamentally into the scheme of things and needs some careful thinking to even work/be compatible.

In play-modes that are not driven by external midi clock coming in to the C64, it will be possible to control the timer values though, and to do so directly from the sidtab.

defMON2 is also going to offer more ways to do live tweaking (including the use of paddles). There will be something called "the buffer", which is like a little table of values that can be used in an almost "modular synthesis" kind of way by the sidtab. So you could slide a value in the buffer, and use that to make a filter slide. Then you could also affect the same value by moving the paddles. ...and things like this.

(All of this is obviously assuming that defMON 2 will ever see the light of the day. I hope it will, and according to my plans it will. I'm only saying that you never know until it has actually happened.)

3. Ahh.. I read "notes" as in musical notes, rather than textual notes. Now I get what you meant!

6. Yes, that one is a really reasonable/natural/logical feature to request. By the way, I am actually able to pack 2SID tunes into executable form using some custom scripts on my mac. It involves some manual work, so it isn't really a service I can offer on a regular basis, but let's say you have one or a few tunes that you really really want to be able to use in some particular production or so, send me a message and I'll see what I can do.

@F7sus4: Yes, I intend to keep fixing bugs in the original defMON to some extent. The pattern overwrite bug is a mystery at the moment though, so that one won't be fixed until I somehow manage to find a clue what might cause it. I have a feeling that this bug is coming from an unexpected direction. Maybe something like the filter bug you reported at some point, which wasn't due to any error in the filter code, but due to a memory leak in an entirely different part of the code.

New features aren't really planned for the original defMON, although not impossible.

Regarding features/ideas for defMON2, there is certainly no harm done in telling me about it. It is quite likely that the ideas will be ignored, since there are so many limitations when doing stuff for the C64, and it is darn complicated to make everything work as it is, but.. like I said. There is no harm in telling me about the ideas. Who knows, maybe some idea will actually make it into the editor in some way or another.

Thanks also for your work in reporting  bugs in defMON. It is very much appreciated.

@d3Ni$e: Good to hear that it worked out in the end. Regarding the "jumping to the same row" thing, it is of course really hard to know that this should be avoided, given the lack of proper manual/documentation of defMON. I really should do that tutorial that I have been thinking about. Let's see if I ever find the time. It is a tough call whether to prioritise something like that, or to prioritise work on a sequel to defMON.