1

(417 replies, posted in Commodore Computers)

frantic wrote:

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.

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.

Usually the cost of having the last note/position "missing" is smaller (and avoidable with some creativity) when compared to the possibility to call additional instructions from sidTAB for the current sequence (not necessarily just hard-restarts, but also filter envelope/markers/offsets, for example). The -1 position is also a perfect place to put sounds with slower attack rate (e.g. strings), so they can synchronize with the short/fast-paced ones (e.g. drumset) better.

In a classical tracker we could technically close the gate for ADSR restart at the end of each sound/note instead of "before". I think it's a matter of design and user preference. To me, defMON is perfect as it is.

2

(417 replies, posted in Commodore Computers)

To put it into perspective, it's pretty similar to either playing triplets in 4/4 or plain quarter-notes in 3/4. While the notation looks different, the outcome will technically sound the same.

frantic wrote:

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.

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

SIDs 6582 and 6582A are 8580s that were used as replacement parts, most indeed were manufactured in 1992. They sound like 8580, and so does yours. Keep in mind that the sound of SID chips (even 8580 to some extent) may vary, especially in the filter departament.

Fake "China" SID chips do not produce any sound at all. They are just random chips that share the same physical measurements and amount of pins, therefore they are likely to damage your machine.

4

(417 replies, posted in Commodore Computers)

Sometimes people's own behavior is their biggest humiliation.

When you're a person (along with second account, which supposedly belongs to a girlfriend) obviously hate-voting all productions and a CSDb profile with 1/10 ratings of someone, because that person "dared" to say your debut work feels unpolished - there might be something wrong with you, not others.

When you then decide to spam multiple obscure-languaged and barely comprehensible posts here at chipmusic.org pointing at someone personally, which aren't even a response to any discussion that previously happened, and these posts become ban-deleted by the moderators - there might be something wrong with you, not others.

And if that wasn't enough, when you continue to spam Frantic's defMON forum with the same sort of messages nevertheless - there might be something wrong with you, not others.

These are facts, this is what you have done, and you seem to be utterly unaware on why this is wrong. With that being said, please do not bother me again, thank you.

5

(417 replies, posted in Commodore Computers)

Agreed. While Vice 3.4 seem to emulate the rather quirky ADSR behavior way more reliably than any other existing software, in the sound department (especially filters), it's reSID-fp based Vice 2.4 that does the job.

6

(417 replies, posted in Commodore Computers)

d3Ni$e wrote:

Well Im in a situation that I need a smaller tune that the packer did for me.
I was thinking to use the whole tune but it was too large so I go: "okey I'll try just 1 minute of it and go for it but with no luck so I got a bit frustrated and limited the tune to like 05 seconds! but no luck there either.. It went down from $2041 to $2019 lol.

Many coders used to reserve music area up to $1FFF (from $1000) in contemporary demos, and even though it's relatively carved-in-stone custom, there's little point for it to be that way, since (pragmatically speaking) no harm will be done if it exceeds $1FFF a bit.

There is always a possibility to load subsequent chunks of code/graphic/data more flexibly (assuming out of memory scenarios), and relocation is yet another possibility (this is what we did in NGC1277).

By the way, significant part of file size optimization lies on the musician. The fewer instrument lines are being used, the smaller the compiled file will become. The same applies to notes and sound-program/instrument numbers used in sequences/patterns. So it is possible to shrink the file noticeably with a bit of strategic approach to composing. GL! smile

7

(417 replies, posted in Commodore Computers)

Yes, to my understanding, "recording" filter envelopes on the fly would probably also come with the problem of truncating grabbed data into time frames/delays compatible with the music speed/timing (even assuming that the recording itself could be RAM-efficient enough).

Nevertheless, paddle support for tracked sequences' playback is more than any (defMON) musician could ever dream of. heart

8

(417 replies, posted in Commodore Computers)

frantic wrote:

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.

Uhm, so if I understand correctly, one of the features would be grabbing/recording filter "envelopes" via the real-time paddles/knobs manipulation into "the buffer table", and then allowing it to use as a sort of preset? If so, standing ovations. big_smile

9

(417 replies, posted in Commodore Computers)

F7sus4 wrote:

- Multi-speed/timer setting change via command. From musicians' POV, a lot of versatility lies behind the concept.

During several live experiments I've realized that switching between x1/x2/x4/x8 speed modes provides interesting "deconstructing" potential to the music. So far, we're bound to one fixed timer setting ($2663, $1CC7 and so on), but if it would be possible to adjust/shift it via command (sidtab program, sequence-specific command, whatever) well, that would change a lot.

10

(417 replies, posted in Commodore Computers)

I was afraid to start a request-fest. Sorry for that, Frantic.

Basically, what I intended to share was 2-3 particular concepts that kept coming back to my mind during the years, and which I'd find at least innovative in any C64 tracker software:

- Randomizer. That's it. Be it waveform, filter value, filter type or whatever.

- Paddles support. This is more live-act fronted, but anyway - if preprogrammed filter values (or sidtab programs) could be affected by global CP offset via paddles just the for purposes of the playback, that would be an extremely powerful feature.

- Multi-speed/timer setting change via command. From musicians' POV, a lot of versatility lies behind the concept.

11

(417 replies, posted in Commodore Computers)

frantic wrote:

COMMA/PERIOD = transpose current step up/down
SHIFT + COMMA/PERIOD = transpose current sequence up/down

I don't really know how much time and effort would implementing such feature into defMON take, but it's probably one of those good all around QoL stuff to have. Not crucial, but important.

I understand defMON2 will become a priority soon, so there goes the question if defMON is planned to reach some sort of retired/final safe-and-stable version? I'm still thinking about 2SID bugs including copying and channel mute (visual), and probably even more than multispeed stability issue, since the latter is at least manageable.

Also, my best words for defMON2. If it happens for you to collect brainstormed input (not requests, but ideas), I'm open to the subject.

12

(417 replies, posted in Commodore Computers)

I was thinking about the whole-sequence transposition as well, but sometimes not having a functionality leads to greater good.

For example, a lot of contemporary GoatTracker2 tunes sound tedious since C64 musicians started to share their skillfully crafted "trademark" instruments. In defMON, every single tune puts you in carte blanché scenario, which is good for creativity. You do music, but don't redo it.

I understand that global transpose might come in handy, but if you actually have to retype every single note, there comes the chance that you'll tweak something in the new sequence a bit, getting more and more variety.

(A small preview of my forthcoming tune @defMON/8580).

13

(417 replies, posted in Commodore Computers)

@Frantic: Done.

14

(417 replies, posted in Commodore Computers)

Custom multi-speed setting stability issue:

defMON by default supports x1, x2, x4 and x8 multispeed mode, which in timer settings translates to $2663 for x2, $1331 for x4 etc.

However, we are also free to achieve x3 multispeed with $1997 manual setting (same with e.g. x6 or x9).

Now, if we choose x2 mode first and we slide the timer down to $1997, it will work stable in the new "custom" x3 mode. But if we choose x4 mode and slide the timer up to $1997, the pattern will play twice as slow as previously and the software will suffer from multi-second hangups in which there will be no response from the keyboard input. This state will pass after a minute or two, but it renders the program unusable during the time.

15

(417 replies, posted in Commodore Computers)

Random thoughts on the "pattern overwrite bug":

I've spent several hours trying to trigger the bug with clean start yesterday, but with no luck. This leads me to assumption that the circumstances involved are complicated. It always happened during multi-hour extensive music editing.

Gut feeling/guess: I also remember reporting that deleting large chunks of instrument data might result in misbehaving sound and (sometimes) corrupted file after saving. This leads me to conjecture that there could be some sort of data leakage in this area which might also interfere with pattern data resulting in said behavior. If not, there are no other existing-and-pending data issues I could think of right now. Will keep looking.

16

(417 replies, posted in Commodore Computers)

deni$e wrote:

When creating patterns ALWAYS keep them in the Seq-list! For me it is more flexible to work like that also. If I have some patterns Im unsure about to use (just a few) or want to try out later I just put them under the "FF" row in Seq-list for an easier access later on.

This is quite obvious practice, since patterns not stored in the sequence list will not be saved to disk, which is why the tracker assumes they were abandoned and safe to overwrite. However, described bug happens regardless of that.

deni$e wrote:

This projects from this user is so rad https://www.youtube.com/watch?v=rudz9QbDh68&t=6s and maybe he/she is around here?

Yes, these were my previews for 25Hz compo at CSDb that I shared with my friends and forgot to set the private flag. The music is already finished and now released.