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

Welcome to our latest new user Harvey ! (Registered 2024-11-25)

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-23 10:26

Jammer

Registered: Nov 2002
Posts: 1335

@Karmic: why entries are limited to singlespeed? It's wrapper's part how we call tune and it has nothing to do with driver meeting or not meeting compo limitations. Honestly, I find this particular rule kinda irrelevant.

2022-02-23 10:31

Krill

Registered: Apr 2002
Posts: 2969

Quoting Jammer

@Karmic: why entries are limited to singlespeed? It's wrapper's part how we call tune and it has nothing to do with driver meeting or not meeting compo limitations. Honestly, I find this particular rule kinda irrelevant.

Agreed, that rule seems kind of arbitrary.

2022-02-23 11:10

Dano

Registered: Jul 2004
Posts: 231

One sidenote from me: When Toggle joined Padua he was doing musics in the full version of the SidWizard. The more comfort in composing lead to large tunes and more rastertime usage.

For demos he needs to do music in the minimal player and make more stuff by hand, optimize things to stay in our memory limit.

I guess with modern trackers you have sort of limited possibilities in making tunes smaller by carefully crafting your patterns and things.

Back to the topic: I suppose Karmic just wanted a compo with as small as possible musics as a result. With musics that actually sound awesome.

I guess the musicians who have access to code or coders that provide a structure for small tunes is limited, just because i suppose 90% of the musicians cannot code some sort of player themselves. And i would suppose that 95% of those tiny players are not publically available.

Don't slam on musicians who cannot code - rather give them access to tools to make tiny musics then.

2022-02-23 11:21

Hate Bush

Registered: Jul 2002
Posts: 461

so the answer to all questions seems to be: modern tunes got bigger and more complex because only a fraction of them is made upon coder's request (or made to be used in any production at all). if you don't have to optimize, you don't optimize :)

2022-02-23 11:23

Krill

Registered: Apr 2002
Posts: 2969

Quoting Dano

And i would suppose that 95% of those tiny players are not publically available.

Some good ones are available in source (including some routines by GRG himself), and that's all that counts.

Quoting Dano

Don't slam on musicians who cannot code - rather give them access to tools to make tiny musics then.

The musicians are not to blame, coding is not their job. :)

The main blame is on lazy coders just re-using the same existing minitunes over and over again.

2022-02-23 11:29

Dano

Registered: Jul 2004
Posts: 231

Quote: Quoting Dano
And i would suppose that 95% of those tiny players are not publically available.
Some good ones are available in source (including some routines by GRG himself), and that's all that counts.

Quoting Dano
Don't slam on musicians who cannot code - rather give them access to tools to make tiny musics then.
The musicians are not to blame, coding is not their job. :)

The main blame is on lazy coders just re-using the same existing minitunes over and over again.

Quote:

Some good ones are available in source (including some routines by GRG himself), and that's all that counts.

Maybe it makes sense to list those here then?

Quote:

The main blame is on lazy coders just re-using the same existing minitunes over and over again.

Yeah, it took me a while to find one for my lame 4k intro back then.

2022-02-23 11:38

deetsay

Registered: Aug 2005
Posts: 43

Quoting vincenzo

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.

Funny, it's pretty much the opposite for me. Modern tools are limitless, nothing is never "done", there's always another channel you can add, another plugin you can try, a thing you can twist... On the C64 it's actually possible to finish a tune and say "I've bumped into the limits now so I guess this is done".

2022-02-23 11:53

Krill

Registered: Apr 2002
Posts: 2969

Quoting Dano

Maybe it makes sense to list those here then?

I may dig around for a bit.

I was mistaken in GRG's routine being released in source, though. I took the liberty to upload it: Plaster (Hope you don't mind, Glenn! :D)
The player in music.s in Artefacts is based on GRG's player, and, well, open-source since release back in 2006. It became the basis for the ~512 bytes tune of Softwired =)

Edit: And ChristopherJam pointed me at 1kplay =)

Quote:

Yeah, it took me a while to find one for my lame 4k intro back then.

4K intro (ICC rules) or 4K demo (standard rules)? :)

Because for the latter, you don't need any coding skills at all to compose a tune in about $0600 bytes with existing editors+players, as seen in various 4K demos. :)

2022-02-23 22:59

Henne

Registered: Feb 2005
Posts: 26

Hi!
You can find the source code of some TinySID compo entries + explanations in the SIDin magazine, e.g. this one: SIDin #10

2022-02-24 08:23

vincenzo

Registered: Sep 2003
Posts: 83

Quote: Quoting vincenzo
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.

Funny, it's pretty much the opposite for me. Modern tools are limitless, nothing is never "done", there's always another channel you can add, another plugin you can try, a thing you can twist... On the C64 it's actually possible to finish a tune and say "I've bumped into the limits now so I guess this is done".

What I was referring to is the way of instrument design and handling notes.
The SID is basically a substractive synthesizer. On a VST or hardware synth you have the knobs and faders to define the sound. In most of the cases there's also visual indication of parameters and waveforms, so you always know what you modify.
On a C64 with numeric editors it's completely different. Yes, it's a substractive synthesizer but without obvious feedback.

If I'm new to the C64, how would I know that waveform 1x is triangle, 2x is sawtooth, and their combination is 3x? Gate on/off 0/1? Same with the filter, 9/A/B/C/D/E, cutoff is XX or sometimes XXX. Not to mention that the "LFO" to modulate parameters is basically a triangle LFO that works with adding or substracting values to the initial value over time. What is a hardrestart, why should I use it and how the hell do I define it if the player like defMON or Virtuoso give you complete freedom to do it?

So yeah, we grew up with the numeric editors, they make perfect sense on the C64 but probably we got so used to it that we forget about usability and user experience.
Would composers create better songs with better UI's? Does it worth the effort to make a completely new music editor interface just because of a couple of composers would be happier? Would more people try to make music on the C64 with visually more satisfying editors? Would it be good for the scene or it would be flooded with crap tunes?

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

Refresh

Subscribe to this thread: