1

(438 replies, posted in Commodore Computers)

In my opinion, there's very little reason to force 6 voices into 1 screen, and from UI/user's point of view I can see several issues with it: 1) SID1 and SID2 sequence list may utilize different loop points or even play at different speeds, which makes the conjoined "current sequence marker" redundant or at least problematic to display properly, 2) SID1 and SID2 do not share the same filter type/value/envelopes, so the filter behavior between voices might become counter-intuitive for some users, 3) the same applies to ring-modulation/sync links between the voices, 4) small fonts on (yet even smaller) CRT screens might become unreadable, defMON still is a native C64 tracker.

frantic wrote:

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

Both ways seem like great ideas and I'll try to support them outside of the forums as much as possible.

Amelinium wrote:

Is this an actual c64 defmon recording?

If you're asking if the recording comes from real C64 machine then the answer is no. This is Vice 2.4 video-grab utilizing reSID-fp emulation (which I highly recommend), in this case: SID 6581R4AR model (one of many, as they all sound dramatically different).

2

(438 replies, posted in Commodore Computers)

2SID mode bug: loop visual desync.

Let's say we're composing 2SID music.

On SID1 we use FF0000 to indefintely loop the first sequence line in the order list.

On SID2 we use FF0100 to indefintely loop two (or more, it doesn't matter) sequence lines in the order list (while SID1 has only one sequence line looped at the time).

Bug: The display (F5) for SID2 becomes stuck in the sequence loop that was meant for SID1, but it still plays the song normally.

This is purely visual, but if the song happens to utilize many loop points in different places for SID1 and SID2, the display will become heavily desynchronized. There's no workaround right now other than to manually transform loops into subsequent sequences in the order list.

To better visualize the issue, here's a video (please note that the 00 sequence should be empty here):
https://www.youtube.com/watch?v=NQFuNKok8Fs

3

(438 replies, posted in Commodore Computers)

@martin_demsky There's nothing preventing you from placing A6 note at -1 position. This is exactly what we were talking about with Frantic right above your post. You can also program instrument 65 to play that arpeggio for you, instead of typing enormous amounts of notes in the sequences.

4

(438 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.

5

(438 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.

7

(438 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.

8

(438 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.

9

(438 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

10

(438 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

11

(438 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

12

(438 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.

13

(438 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.

14

(438 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.

15

(438 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).

16

(438 replies, posted in Commodore Computers)

@Frantic: Done.