[CSDb] - User Forums - Event id #3157 : Unofficial Tiny SID Compo 2022

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Event id #3157 : Unofficial Tiny SID Compo 2022

2022-02-05 00:20

Karmic

Registered: Apr 2015
Posts: 66

Event id #3157 : Unofficial Tiny SID Compo 2022

Welcome to the Unofficial Tiny SID Compo 2022.

Rationale
Now, as you may be aware, recently in the scene there has been an uptick in people using so-called "tiny" SIDs, mostly thanks to Didi & Richard's series of Intro Creation Compos, where the intros are only allowed to use a certain block of RAM. The problem with this is that there is a severe lack of decent tiny SIDs out there- all it takes is a little bit of browsing through the comments of ICC2021 entries to see some discontentment over the same old GRG tunes being reused over and over again. Now unfortunately this compo comes a little too late to rectify that particular situation, but I believe that even outside of the ICC2021 context, coders will appreciate having a wider library of tiny SIDs to choose from for their killer RAM-eating effects.

This compo idea does have precedent- Stefano Tognon (Ice00) has previously hosted some Tiny SID Compos 15 or so years ago, which got a decent amount of entries. My rules are fairly different from his, though.

Rules
The goal of this compo is to produce a self-contained tune, where, with the exception of the zeropage and stack, the entire RAM area used by the tune is contained in one 512b/1kb/2kb (depending on the category) block.

The exact technical rules by which your tunes will be judged are as follows:
- All code, data, and non-zeropage variables that are required for your tune to play should fit in one continuous block of the size specified by the category. Your music code is not allowed to access any non-zeropage RAM outside of this range.
- Your music code should not rely on the initial state of any zeropage location.
- Stack area ($01xx) must only be accessed conventionally, as a stack. That is, only use JSR, RTS, PHA, PLA, PHP, and PLP. Most stack tricks hurt the self-contained-ness of your code.
- Your music code cannot access any I/O registers outside of $D400-$D41B.
- Your music code cannot access any of the ROMs (kernal, basic, chargen).
- Your music code cannot access $00-$01. A coder certainly won't like it if his SID interferes with the bank configuration.
- To give tunes some zeropage "breathing room", your music code cannot access $02-$07.
- Your music code cannot access $0200-$033B, $D000-$DFFF (the RAM under I/O), or $FFFA-$FFFF. Again, a coder won't like it if you mess with these.
- Your music code cannot change the I bit in the CPU status register. So, no SEI, no CLI, and any PLP should be accompanied by a corresponding PHP.
- If you find a use for the decimal mode, you must make sure you turn it off before your music code exits. You can safely assume decimal mode is off at the entry points of your music code.
- Your music routines should be accessible like a PSID file, with an init entry point that exits with an RTS, and a play entry point that executes once per frame, and exits with an RTS.

Be aware that none of the above rules apply to any code that presents your music. As per CSDb rules, you must provide an executable. A good way to think about it is: if we in HVSC had to rip your tune as a SID, which code and data would we have to include?

To make up for the extreme technical restrictions, I am giving you very little creative restrictions:
- Covers and tiny adaptations of other SID tunes ARE allowed.
- It IS allowed to use a player made by someone else, but your tune must be wholly new and not just a cheap edit of the original.
- One composer can enter a maximum of 2 tunes per category.
- Your tune must last for at least 10 seconds before it loops.
- Your tune's presentation must be fairly minimal. Some text, a logo, and an equalizer is okay, but you can't submit a whole demopart and call it a "music entry".

When adding your entries to CSDb, please use the "512b/1K/2K Game" compos. This looks odd but at the end of the day gives the best at-a-glance look at the categories.

The entry period lasts from right now until May 7th, 11:59 PM CSDb time (CET). Depending on the amount of entries, I will either use an external votesheet or you will vote right on CSDb. We'll see.

Tips
If you are a musician who is not a coder, you probably know someone who is and would be willing to help you. If you really don't, you can at least enter the 2k category with a tune in a slim player such as GoatTracker or NinjaTracker.

... 86 posts hidden. Click here to view all posts....

2022-02-22 16:07

DeMOSic

Registered: Aug 2021
Posts: 126

Quote: Real coders let the tune compose itself!

(Code a player for procedural/generative music and have a tune that's impossibly long and diversely structured for the size, or something.)

Those are awesome! And one guy has done it REAL good in Basic (Alan Bond is the guy)

2022-02-22 16:57

Karmic

Registered: Apr 2015
Posts: 66

This discussion is very interesting. I have to agree that 2k isn't really tiny, and that I only included it to give non-coder musicians a chance to enter something. If I had known that there'd be a new tiny-tracker almost immediately after I started the compo, there'd be no 2k category at all. And there are too many 2k entries now to just disqualify them all.

By the way I'm not personally against generic "tiny musical programs" that have free reign over the entire C64, in fact it seems like a great idea for a future compo. I just wanted to get this "lack of small reusable SIDs" problem solved first.

2022-02-22 23:03

spider-j

Registered: Oct 2004
Posts: 498

As deetsays statistic already shows: the closer you come to "today" the lesser "small" tunes are released. Nowadays it is quite common to release tunes in music competitions that are 6K, 8K, 10K and even bigger... I'm talking about "normal" 1x "no sample" tunes here btw.

Compared to that 2K *is* "tiny". Doesn't really matter how many tunes of smaller size are in HVSC, when half of them are shit and the other halfs half is old stuff reused again and again.

And even with all of the tools we have nowadays, it's not that easy for musicians to stay within the limits of the players *and* come up with at least half decent music. And then it also must fit your intro screen.

There are may variables and there's is always room for more music. Be it with a self coded routine or just "lame" using others tool like I do.

EDIT: just to make it crystal clear and avoid misunderstanding I added "Code" credits on my tunes for this compo – crediting the authors of the play routines.

2022-02-23 01:28

Krill

Registered: Apr 2002
Posts: 2968

Quoting spider-j

Nowadays it is quite common to release tunes in music competitions that are 6K, 8K, 10K and even bigger... I'm talking about "normal" 1x "no sample" tunes here btw.

This is an interesting factoid.

Do you have any theory as to why it is as it is?

2022-02-23 07:56

vincenzo

Registered: Sep 2003
Posts: 83

Quote: Quoting spider-j
Nowadays it is quite common to release tunes in music competitions that are 6K, 8K, 10K and even bigger... I'm talking about "normal" 1x "no sample" tunes here btw.
This is an interesting factoid.

Do you have any theory as to why it is as it is?

Wall of text is incoming.

From my point of view this whole question of composing music on obsolete computers looks like this:
Back then, when I started to make music with DMC, I had no idea what is sound synthesis, what is programming and how does a computer work basically. All I did was to examine other people's music and experiment with random numbers in the editor. On top of this, I tried to use my music theory knowledge, which, at that time was also very limited. This whole procedure was fun, because I was curious and wanted to make music with the only tool I had, a C64.

Later, I learned about synthesizers, more music theory, played keyboard, etc. It helped a lot with musicality but didn't help with understanding the SID itself.
I tried to learn programming, I really did it many times but I failed. My brain just doesn't accept it and programming is still magic to me.
And now, I would like to bring this to the topic of making music on an obsolete computer with tools that directly send data to a chip and have a very minimalistic, numeric interface.
It's freakin' awesome that we have these tools! From a musician point of view, remember, to a musician who wants to make music, it's a dream that at least there's an interface that allows me to enter fairly understandable values and on the other end some bleep bloop will be audible.
However, it's still a lot of numbers that has very little relation to the classic meaning of music.

Back then, we had time and passion to experiment and learn stuff, so it wasn't really an issue to musicians to do some basic programming too. Nowadays, and this is basically the conclusion of last year's Grand Tour Challenge too, we just don't have the time or the every day energy to learn this shit. Mostly, because modern tools make us comfortable, visual feedback of a music is very important too and that's nonexistent on a C64. C64 music still requires programming knowledge, especially when we go to the more experimental territory like tiny music.
And I believe this is basically the reason for having so few composers and new, young faces on the scene too. Time has changed, we are used to the tools that help us releasing our creative energy and make music quickly, and the workflow is tailored to the musician's brain where we don't have to understand numbers and coding. It's also a bit on the funny side, because music can be easily described with math and numbers.

So, conclusion and TLDR: the more modern the tool for music is the better for the average musician. The more visual and immediate feedback on the UI is the better from composing point of view. Coding your own tiny player is fun and beautiful, but sorry, I'm not interested in coding. I'm a musician with a musician's brain and I appreciate all the effort from a programmer of supporting me with a proper tool, where I can use my musician fantasy to compose something that might be musically interesting.

2022-02-23 08:29

Krill

Registered: Apr 2002
Posts: 2968

So your point is, C-64 music got more wasteful and less good in musical terms on average because... the easier modern tools allow for more mediocre musicians to dabble around, contrary to the native minimal editors of old, with their number salad input? :)

2022-02-23 08:33

vincenzo

Registered: Sep 2003
Posts: 83

Quote: So your point is, C-64 music got more wasteful and less good in musical terms on average because... the easier modern tools allow for more mediocre musicians to dabble around, contrary to the native minimal editors of old, with their number salad input? :)

If you interpret my words like this, then the answer is probably yes. It's a time consuming hobby that makes not much sense nowadays but we still love to do it. What you probably miss in my sentences is that I'm not shaming it but highly appreciate this whole demoscene thing and passion. That's why I'm here, doing music because I enjoy doing it.
However, I'm an old fart and got too comfortable with the modern tools I use in my professional life. Working with an ancient C64 editor is a pain. It's beautiful, but it hurts.

If a "mediocre" musician is able to do a mediocre music, then it's still a music that's been made on a C64. The audience will judge the quality.
However, people on the scene usually cry that there are no new faces and the demoscene is dead. Yupp, it is, and in my opinion it's partially because of the judgemental behavior of people.
People expect constructive feedback and they ususally appreciate it so they can evolve and be better. But if that feedback is negative and shaming, then it just simply doesn't help the person and the person's (musical or whatever) development.

2022-02-23 08:39

Krill

Registered: Apr 2002
Posts: 2968

But the comfy modern editors for modern platforms exist, and i'm pretty sure allow for good music, too. :)

I've never looked at them closely, but could it be their SID driver backend (the stuff that ultimately runs on the C-64) isn't so well-optimised in general?

2022-02-23 08:44

vincenzo

Registered: Sep 2003
Posts: 83

Quote: But the comfy modern editors for modern platforms exist, and i'm pretty sure allow for good music, too. :)

I've never looked at them closely, but could it be their SID driver backend (the stuff that ultimately runs on the C-64) isn't so well-optimised in general?

I have no clue about the driver's side of modern crossplatform C64 music editors (nor the old ones on C64). In my opninion, it's the numeric input that makes it a bit fiddly to make some music - and in some cases the lack of documentation too.
A great example of well documented tool is SID-Wizard and its extensive PDF. It even explains the SID's features in a very good way that musicians can relate to.
Let's take Goat Tracker as a modern tool example, or SID Factory II. They are great for composing music and they are the most modern tools in existence. They are still numeric and are pretty far away from a Cubase, Protools, Logic, or even Fast Tracker or Renoise too.

2022-02-23 08:53

Krill

Registered: Apr 2002
Posts: 2968

There are a couple of projects implementing VST plug-ins for SID creation, unleashing all the goodies of modern DAWs, but none of them so far seem in any usable state. (Unless i have missed a smashing release.)

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next

Refresh

Subscribe to this thread: