| |
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. |
|
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
yay! an original compo :) looking forward to entries :) |
| |
DeMOSic
Registered: Aug 2021
Posts: 126 |
Quote: 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.
Yay! A new TinySID compo! ill try to participate if i can |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
What's the rationale behind those very detailed technical restrictions? (I still haven't fully grasped the gist of them.)
Why isn't executable size (with or without load address/start stub) enough? |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Ah, the idea seems to be maximum reuseability.
Including separate init and play calls.
With conventional usage patterns of zeropage/stack/code/data.
In tiny tunes. For very size-restricted productions.
I dunno. Seems a bit like a contradiction, with avoidable overhead pre-programmed.
But do go ahead. :) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
I understand that particular memory limits concern only driver+data, not whole thing with exec wrapper? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
Thats simply so ppl judge the music, not the fancy demo |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting KrillAh, the idea seems to be maximum reuseability.
Including separate init and play calls.
With conventional usage patterns of zeropage/stack/code/data.
In tiny tunes. For very size-restricted productions.
I dunno. Seems a bit like a contradiction, with avoidable overhead pre-programmed.
But do go ahead. :)
I suppose it does, after all, if I didn't restrict you in these ways you could certainly find ways to make the code smaller. But it does go against the mission of the compo, which is to give intro-coders a wider variety of easily usable small SIDs to choose from. Purely judging on executable size would certainly be valid for a "whole product" (like a demo), but this compo is not about producing "whole products". It's more like you're making an "ingredient" that a demo-chef can make part of his recipe, and for this to work, your ingredient must be able to coexist with other things in the same bowl.
I don't think most of the limits are hard, most of them aren't even really limits, it's just "regular" practice. Lots of PSIDs in HVSC follow these rules (aside from the size restriction) already. Unless you actively try to break them, you probably won't.
Quoting JammerI understand that particular memory limits concern only driver+data, not whole thing with exec wrapper?
Yeah. The guideline is, only anything that would have to be included in a SID file is counted. |
| |
The Syndrom
Registered: Aug 2005
Posts: 55 |
I like the idea... challenge accepted.. |
| |
Frostbyte
Registered: Aug 2003
Posts: 165 |
Brilliant, thanks for organising this, and thanks for a reasonable entry period too. May even have time to do something for this, or at least attempt to. :)
I fully understand the strict rules, which enforce the "self-containment" and thus make the music actually useable in real life prods. Also I appreciate the "music, not a demo part" rule. :) Only a couple of things I'd want to nitpick about:
"- Your music code cannot access any I/O registers outside of $D400-$D41B."
This should probably be up to $D41C, which is the last SID register (voice 3 ADSR output)? Leaving it out prevents implementing some custom tricks (e.g. filter curves) based on it.
Also, everything from $D420 to $D7FF is just shadows of SID registers. Allowing usage of the shadow registers could possibly help shave off a few bytes from here and there, depending on the player implementation. This could be valuable especially for 512b entries. But just thinking aloud here, really.
And just to further clarify:
"- 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."
So in short, the tune can utilize the ZP from $08 to $FF in any way it sees fit (temp variables, player code, music data)? |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Quote:But it does go against the mission of the compo, which is to give intro-coders a wider variety of easily usable small SIDs to choose from.
I think this is a good priority! Easier usability is worth more than the few saved bytes possibly gained by weird trickery. |
| |
DeMOSic
Registered: Aug 2021
Posts: 126 |
im wondering. is it too much if i for example just make a simple PETSCII and add a Scroller as an executable? |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting Frostbyte"- Your music code cannot access any I/O registers outside of $D400-$D41B."
This should probably be up to $D41C, which is the last SID register (voice 3 ADSR output)?
Yes, you can access $D41C too. Sorry for the typo.
Quoting FrostbyteAlso, everything from $D420 to $D7FF is just shadows of SID registers.
That does work, until the user has extra SIDs installed... or maybe it's not a big deal. Before I actually allow it I'd like to hear from people who actually have this stuff installed on their real machine, if it makes life inconvenient for them that SIDs go writing willy-nilly into the mirrors.
Quoting That8BitChiptuneGuyim wondering. is it too much if i for example just make a simple PETSCII and add a Scroller as an executable?
Nope. I'll try not to be too hard on that rule.
By the way, to clarify, you should enter your entry into the "Game" compos on the compo entry. The CSDb category your entry should be in is C64 Music, as usual. |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting FrostbyteSo in short, the tune can utilize the ZP from $08 to $FF in any way it sees fit (temp variables, player code, music data)?
Yes, but to be clear, any code that initializes zeropage required by the rest of the music code is also counted as music code, since your tune wouldn't play right without it. |
| |
TheRyk
Registered: Mar 2009
Posts: 2047 |
Quote:Covers and tiny adaptations of other SID tunes ARE allowed.
Yay! :) |
| |
Steel
Registered: May 2006
Posts: 6 |
as a non coder. what would it require for packing options in GT? |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Quoting Steelas a non coder. what would it require for packing options in GT?
If you don't use certain features like filtering or pwm, compiler will remove that code to save on size. Still, you're running in 1kb category at least, even with very short tune ;) |
| |
Steel
Registered: May 2006
Posts: 6 |
Quote: Quoting Steelas a non coder. what would it require for packing options in GT?
If you don't use certain features like filtering or pwm, compiler will remove that code to save on size. Still, you're running in 1kb category at least, even with very short tune ;)
so i will have do a song without filter and pwm in GT? did i copy that right? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
Not specifically. You might want to start with a tune that uses barely any features at all, and pack that and see how big it comes out. And then add certain features and try again. Etc |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting KarmicThat does work, until the user has extra SIDs installed... or maybe it's not a big deal. Before I actually allow it I'd like to hear from people who actually have this stuff installed on their real machine, if it makes life inconvenient for them that SIDs go writing willy-nilly into the mirrors.
Nobody said anything, and there are already two entries (by Hermit and Chabee) using the mirrors, so I'm allowing it. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Quote: Quoting KarmicThat does work, until the user has extra SIDs installed... or maybe it's not a big deal. Before I actually allow it I'd like to hear from people who actually have this stuff installed on their real machine, if it makes life inconvenient for them that SIDs go writing willy-nilly into the mirrors.
Nobody said anything, and there are already two entries (by Hermit and Chabee) using the mirrors, so I'm allowing it.
To be precise they don't "use" the sid regs mirrors, the init at $1000 only clears $3f bytes from $d400, only because it reuses the loop index to clear the ZP vars and save some bytes. The actual play call at $1010 only uses regular $d400-$d418 writes.
Besides, the posted .sid files in their entries lack the init address set to $1000, they have $0000 and it's invalid. Just saying. /me looks at Hermit |
| |
TheRyk
Registered: Mar 2009
Posts: 2047 |
@Steel: Also be aware, there is a 2k category, I don't see how it's impossible to use any filters in GT within a 2k tune. |
| |
Conrad
Registered: Nov 2006
Posts: 833 |
When it comes to calling the init routine, are you allowed to set the accumulator (as well as X/Y) before doing the JSR? If not, then I would assume that the accumulator should be #$00, simply because a PSID has it set to that as well? (unless it's a set of subtunes)
e.g.
JSR $1000
and not:
LDA #$00
JSR $1000 |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting ConradWhen it comes to calling the init routine, are you allowed to set the accumulator (as well as X/Y) before doing the JSR? If not, then I would assume that the accumulator should be #$00, simply because a PSID has it set to that as well? (unless it's a set of subtunes)
e.g.
JSR $1000
and not:
LDA #$00
JSR $1000
PSID environment, so your init routine can safely rely on A being $00 on entry, but nothing else. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
IMHO you don't have to assume anything if you want to use a tune on an actual C64 program, initialize everything you need.
Or is this compo for .sid files only? I don't think so. |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting iAN CooGIMHO you don't have to assume anything if you want to use a tune on an actual C64 program, initialize everything you need.
Or is this compo for .sid files only? I don't think so.
OK, on second thought, I have to agree with this... please ignore the previous message, your init/play entry points should not rely on the registers' states. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Any chance for 256b category as well? ;) |
| |
spider-j
Registered: Oct 2004
Posts: 443 |
There you go: 1kTestAcle
Have fun! |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting JammerAny chance for 256b category as well? ;)
Sure, just set the compo as "256b Intro".
In case anyone is wondering, I will not allow any other categories. 256b, 512b, 1k, and 2k are your options. If a category is lacking entries, I'll "merge them up" to the next highest size. |
| |
DeMOSic
Registered: Aug 2021
Posts: 126 |
quick question, does things like 1k mean 1k and under or does it mean 1k to 2k or does 512 mean under 512 or 512 - 1k? |
| |
spider-j
Registered: Oct 2004
Posts: 443 |
Size restrictions in compos usually mean the "upper" limit.
So 1k i.e. means size <= 1k. |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting KarmicTips
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.
Thanks to Hermit's new tracker (FlexSID 1.0), this is outdated. Now you non-coder musicians have no excuse not to participate :) |
| |
Conrad
Registered: Nov 2006
Posts: 833 |
I was going to stay quiet, but fuck it, I really don't care anymore...
Respect to Hermit for FlexSID and nothing personal against him... but after what Karmic has just said, it's practically rendered most of the rules in this compo worthless and it's ruined a real coder's competition. You (Karmic) may as well just remove the entire rule-list on the code limits now and make it a compo for musicians only. I don't know about other coders, but one feels he's wasted a valuable amount of hours/days for nothing.
EOD. |
| |
Hate Bush
Registered: Jul 2002
Posts: 452 |
i'd have more faith in the demoscene audience - i'd bet that doing it in own player, coded from scratch, will be somehow appreciated more than JUST (flexsid being no magic wang either) composing and rendering :) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting ConradI don't know about other coders, but one feels he's wasted a valuable amount of hours/days for nothing. I'm still quite sure that a carefully handcrafted player optimised for a specific tune (and vice versa) will give better results for the same size than any editor+player thing could.
This is the impression i got from having coded a few minitunes here and there, with compositions coming from real musicians. :) |
| |
Hein
Registered: Apr 2004
Posts: 933 |
All I can say is that I had fun coding my tiny music routine. The music I converted to the tiny format was an old piece anyway. |
| |
spider-j
Registered: Oct 2004
Posts: 443 |
@Conrad: what are you talking about? Since when is "It IS allowed to use a player made by someone else" a "real coder's competition"?!? |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting ConradI was going to stay quiet, but fuck it, I really don't care anymore...
Respect to Hermit for FlexSID and nothing personal against him... but after what Karmic has just said, it's practically rendered most of the rules in this compo worthless and it's ruined a real coder's competition. You (Karmic) may as well just remove the entire rule-list on the code limits now and make it a compo for musicians only. I don't know about other coders, but one feels he's wasted a valuable amount of hours/days for nothing.
EOD.
It was never a "real coder's competition". From the beginning I said entrants could use other people's players, and even recommended GT and NinjaTracker for desperate situations. This new tracker is IMO only a good thing, as I'm sure there are a lot of talented composers (e.g. Steel who posted in this thread before) who wanted to participate, couldn't, and now can. It might not seem like it, but aside from the size limits, the rules are not made to limit you, it's just the guidelines that all "reusable" play routines follow already.
Anyway, aside from that, I can only reiterate what Krill and Michal said. I believe that voters will take into account the effort spent on making a player, and when it comes to tiny stuff you always get the best results designing your player "around" the tune instead of using a generic player anyway. You are a good composer and coder so I hope you understand, and continue working on your entry. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
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.) |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting KrillReal 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.)
I'm actually hoping for at least one of these in the compo. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
IIrc, 2K ($0800 bytes) tunes have been around for a while, and can be made with regular editors quite easily.
Things like JCH's newplayer V19 have been around since the early 1990s or so. :)
(That said, 2K may be considered small, but not really "tiny". 1K isn't that tiny either.) |
| |
Ninja
Registered: Jan 2002
Posts: 404 |
I have to agree with Krill. 1 or 2K are also not tiny in my book. 256 and 512 byte tunes were the real challenge back then. But yeah, it is Karmic's compo, if it wasn't for his initiative, we wouldn't have the discussion now.
And Conrad, if you finish your thing, I am sure it will kick major ass anyhow! |
| |
deetsay
Registered: Aug 2005
Posts: 36 |
I made a lot of analysis of SID files some time last year, using a SID header reader that says how many pages the files are using (and which pages, to figure out the best place for a DJ-program to reside in). Only the load address and size of file is considered, of course, this doesn't say if the SID stays within its loading footprint. Luckily most do. The decade depends on the year being written in the first 4 characters of the COPYRIGHT-field (it is *almost* always there). 512b contains only the SIDs that are 257b-512b, 1k is only 513b-1k, etc.
There are *NOT* a lot of SIDs that fit inside a single page, and 2k isn't exactly mainstream either:
80s 90s 00s 10s 20s
256b 25 3 3 6 1
512b 86 4 20 16 11
1k 227 13 36 42 18
2k 681 1106 483 626 178
4k 4549 17768 3748 3535 660
I don't remember which HVSC version was used specifically, don't remember if I had other limiting "search options" and didn't do any double-checking on these numbers, but I'm sure that the idea of scale expressed by the numbers is fairly reliable. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Well that table clearly shows that anything below 1K is home of SID shortage, which this compo aims to address. :)
1K itself is debatable, 2K is plenty. |
| |
deetsay
Registered: Aug 2005
Posts: 36 |
Maybe this is more interesting than just numbers. Should we expect to see World Records broken in this compo? Time to check what the rules say about BASIC... http://www.tero.fi/tinysids.txt |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting deetsayTime to check what the rules say about BASIC... BASIC programs may be hard to wrap into separate init and play JSR-able calls. :) |
| |
deetsay
Registered: Aug 2005
Posts: 36 |
Quote: Quoting deetsayTime to check what the rules say about BASIC... BASIC programs may be hard to wrap into separate init and play JSR-able calls. :)
Yeah (guess those are all RSIDs -- they weren't counted in the original statistic btw) plus another small hurdle is that it seems to be expressly forbidden. |
| |
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) |
| |
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. |
| |
spider-j
Registered: Oct 2004
Posts: 443 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting spider-jNowadays 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? |
| |
vincenzo
Registered: Sep 2003
Posts: 78 |
Quote: Quoting spider-jNowadays 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. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
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? :) |
| |
vincenzo
Registered: Sep 2003
Posts: 78 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
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? |
| |
vincenzo
Registered: Sep 2003
Posts: 78 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
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.) |
| |
vincenzo
Registered: Sep 2003
Posts: 78 |
Quote: 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.)
What are those VST's? I can recall one that is still in development (SIDStep). The others I'm familiar with are emulating the SID sound but they don't export actual .sid or .prg files (SIDizer, quadraSID, Chipsounds and many more VST's).
(we are steering away from the topic, might make sense to bring this conversation to another thread?) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Yes, would make sense. Also the question of missing new talent and young sceners warrants an own discussion thread. (I don't think it's the high bar right for the first release that is a main problem, nor any gatekeeping opinionated jerks slagging off newcomer stuff.) |
| |
spider-j
Registered: Oct 2004
Posts: 443 |
Quoting KrillDo you have any theory as to why it is as it is?
SID tunes got more complex in composition and sound design. At least when we're talking about the typical "top 10" material. Or even beyond that considering that there are often ~20-30 entries in music compos of bigger C64 parties and usually only a handful are more on the "simpler side". |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting spider-jQuoting KrillDo you have any theory as to why it is as it is?
SID tunes got more complex in composition and sound design. Ah, i see. So the bigger size is well-excused then. :) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
@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. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
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. |
| |
Dano
Registered: Jul 2004
Posts: 226 |
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. |
| |
Hate Bush
Registered: Jul 2002
Posts: 452 |
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 :) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting DanoAnd 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 DanoDon'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. |
| |
Dano
Registered: Jul 2004
Posts: 226 |
Quote: Quoting DanoAnd 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 DanoDon'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. |
| |
deetsay
Registered: Aug 2005
Posts: 36 |
Quoting vincenzoHowever, 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". |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting DanoMaybe 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. :) |
| |
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 |
| |
vincenzo
Registered: Sep 2003
Posts: 78 |
Quote: Quoting vincenzoHowever, 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? |
| |
Digger
Registered: Mar 2005
Posts: 421 |
I guess SIDTracker 64 was that attempt to make SID composing available for masses. I am still dreaming about writing an open-source browser based editor that would allow for neat UI experience, e.g. auto chords mapping to intervals, automating param values with bezier curves etc. But it will probably never happen. |
| |
deetsay
Registered: Aug 2005
Posts: 36 |
Quoting vincenzoWhat 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.
OK, hardware synths can be cool, because they can also offer some "creative limitations", but these days they can also be too full of software with no limits. That's the problem: There is no "I wonder what I can do with this today? I wonder if I could do *THAT* on this?" You already know that you can, and somebody has already done it better (whoops, that problem exists with SIDs too). But yeah, you have software with unlimited sliders with unlimited accuracy. Not that you really need them for anything, because there are 25000 presets sorted in 200 categories by genre. Stuff may sound pretty good, but you can also try another plugin. Add another effect on top, no limits. Maybe throw it all away because with all those effects it doesn't feel too neat any more, and go play with that hardware synth instead because you clearly remember that one time you got that sound out of it, so you could sample it (unlimited sample time with unlimited options for beatmatching and stretching of course)...
Quoting vincenzoOn a C64 with numeric editors it's completely different. Yes, it's a substractive synthesizer but without obvious feedback.
Luckily the most important feedback is there: Hearing the audio. And neatly limited options to pick the best sound from.
Quoting vincenzoWould 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?
Making a UI that's better for experts AND good for beginners is not going to be easy. There is no shortage of software, and I'm sure they all did their best. But I'm also sure many will still try... At least for a couple of decades more.
Remember MSSIAH with its piano roll and mouse control? Did anyone do something for the Real C64 scene with it? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
Quote:Remember MSSIAH with its piano roll and mouse control? Did anyone do something for the Real C64 scene with it?
And if not - ask yourself why not.... |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
@Karmic: Any chance to expand compo about a week or so? My new routine is almost done and I'm kinda desperate to finish it :D Or maybe at least till tomorrow/Sunday? |
| |
acrouzet
Registered: May 2020
Posts: 79 |
Quote: 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?
As a younger chiptuner/scener, I cannot count how many times I have seen very talented composers be turned off from trying out SID music by the interfaces of SID trackers. The current options for more accessible tools aren't great at the moment.
There's Deflemask, which is a bug-filled mess that exports pure register dumps.
SidTracker 64 is for a limited platform (iPad), costs money, and is lacking some important features. (It also seems to be in development limbo).
There are some promising developments, though. GTUltra is a step in the right direction, and there's a new multiplatform tracker called Furnace which is supposed to be getting SID export in the future. |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting Jammer@Karmic: Any chance to expand compo about a week or so? My new routine is almost done and I'm kinda desperate to finish it :D Or maybe at least till tomorrow/Sunday?
I'll give another week. Entries are now due at the end of May 14, CET. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Quoting KarmicI'll give another week. Entries are now due at the end of May 14, CET.
That's absolutely generous of You! Thanks! <3 |
| |
Didi
Registered: Nov 2011
Posts: 478 |
A lot of great very small tunes waiting to be used in the upcoming 4k or lower compos. ;-) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Quoting DidiA lot of great very small tunes waiting to be used in the upcoming 4k or lower compos. ;-)
You bet ;) |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Votesheet is now ready, and entries will close in about 2 hours and 20 minutes. |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Entries are now CLOSED. Votesheet is here: https://forms.gle/yxrragogztTxY2Q1A
Voting ends at the end of May 28, in CEST (CSDb time).
I have to say, I was very surprised and pleased at the amount of entries. Thanks for participating, guys! |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
I have 5 votesheets so far. Voting ends in 4 days, so remember to vote if you haven't! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
I'd rather not vote if that means i have to signup with google >_> |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Quoting GroepazI'd rather not vote if that means i have to signup with google >_>
You don't have to, it only allows you to save your progress. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Three categories ranked, one more and I can submit my votesheet tomorrow :)
Some of these are closer than others. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Voted! |
| |
Karmic
Registered: Apr 2015
Posts: 66 |
Voting is now OVER, and the results are in. Out of 13 voters:
256b Category
1. Pocket Universe (8.83)
2. Rozzo (7.75)
3. Compromises (7.08)
4. HerMiniSID-252bytes (7.00)
5. Ambience (6.67)
6. Page Beep (6.50)
7. LFSR-SID (4.67)
512b Category
1. Lift Off (9.17)
2. Rain (8.58)
3. Immortality (8.33)
4. Dark castle (7.67)
5. Paralyzed Bits (7.64)
6. 512 Rap (7.23)
7. MajomTanc (6.83)
8. 1 Byte Under 512 (4.64)
1k Category
1. Selfies from the Ex (8.92)
2. Airport (8.62)
3. Immortality II (8.00)
4. Minisea (7.55)
5. 1kTestAcle (7.50)
6. Size Matters (7.33)
7. Barrel Cortex (6.83)
8. Congratulatheme (6.58)
9. Sweet Martha (6.50)
^. Mini Blues (6.50)
2k Category
1. Quite Close (8.42)
2. MSK Cover-XF End (8.25)
^. Gravity (8.25)
4. Young Poe (8.23)
5. Electric Zoo (7.50)
6. Sunday (7.42)
7. Robust Condor (6.50)
Thanks for participating! Again, I am very pleased at the amount of entries in this compo. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Yes, thanks everyone - some definite gems in here.
And Karmic, thank you so much for organising! Excellent ruleset, and prompted quite a flurry of entries.
Now to pick over a few of the smaller entries for code inspiration :) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Applause for the worthy winners! <3
It was really a compo everyone needed after that long time. I hope next edition is going to launch sooner ;) |
| |
deetsay
Registered: Aug 2005
Posts: 36 |
For next time, I hope for some clarification: Does the tune need to re-initialize *all* it's parameters to the same starting state in every init call? If yes, then that's understandable and fine. However, at least I am interested in revolving as many parameters as possible over time (add, roll, change opcodes). Changing all of these back to the starting state takes a lot of bytes, in a situation where every byte is critical (at least in 256b).
The thing is, there IS a workaround: Just copy everything to zeropage and work from there. That will eat up almost all of it, but for some reason that would be currently allowed. Going ZP with the self-modifying code should save about as much as the copying code takes. But I'm not sure that this is a great option for the rationale -- in a production, a coder might like to have a chunk of the zeropage for something more critical than the music.
And also for the purpose of small demoish productions, restarting the song in exactly the same way doesn't sound like a strictly necessary feature.
So I would propose a ruleset that goes something like:
- The song needs to initialize itself to a playable state in the init code and needs to initialize all data outside the loading footprint (same as now).
- On calling init AGAIN it still needs to initialize all data it uses outside its loading footprint so that it's playable, BUT it DOESN'T have to be exactly the same data as the first time.
- If the song takes that liberty and does not re-init itself completely each time, then the SID file needs to come with a different init code that always fixes everything to the starting state, to stay in line with the standard. This extra init-code is not counted against the size limit.
I know, it's too complicated and probably confusing. But that's what I'm proposing anyway! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
I like where you’re going with that Deetsay. Personally I’d prefer that the version within the size limit not have to support a second call to init at all; as you said, it’s not something that most productions would require, and can definitely entail extra baggage.
Also agreed about how trashing all of zp is likely to be a conflict. Perhaps a future compo could limit that to 64 bytes? Or alternatively, the compo could just require the zp usage be documented with the entry, so voters can include lightness of zp impact in their scoring consideration?
Similar considerations apply to raster usage of course. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
The requirement of a proper init is due to a long history of old songs ripped while playing and natively lacking of a proper init, so they wouldn't restart
with all the voices inited properly, or not even from the first pattern and so on. Imagine being in the old days, when you didn't have the pre-inited
original binary, but wanted to use *THAT* tune, you would rip it from memory and most probably after it started playing.
Another problem of not initing correctly all the vars is due to memory fill patterns different on every C64 depending on the RAM chips mounted.
You (probably) have no idea how many sids got re-ripped in the previous years to fix such silly problems.
A proper init would guarantee the tune playing always the same no matter when it gets re-saved. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Ian: no one is proposing “no init.” We just want the possibility to make an entry where init is only guaranteed to work once, at least in the smaller variant of the release. Of course the compo could also require a .Sid where init works many times, but that would be allowed to exceed the size restriction for the category entered. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
I think Ian is mixing up "hvsc requirements" with "compo requirements", while I understand it from a hvsc perspective, it's not in the rules for this compo. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
> init is only guaranteed to work once
At this point if you only care about it working only once, just do like Dane does from some years, there is NO init at all, you need to have the preinited binary when you link the tune to your prod, that's it, and fuck everybody else, there's an idiot out there that patches a correct init when he rips the tunes for his collection in any case ;)
Burglar: I only wanted to tell an explanation why an init is a good thing. Adding it or not, it's just a matter or caring about who is going to use the tune apart the author himself, or not caring at all. |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quoting iAN CooGBurglar: I only wanted to tell an explanation why an init is a good thing. Adding it or not, it's just a matter or caring about who is going to use the tune apart the author himself, or not caring at all.
I agree, you are correct there, but in the scope of this thread/compo, every byte counts.
I would suggest modifying the rules a tiny bit for any future tinysid compos:
require a .sid including proper init (exactly as you specified), but the music code+data in the (also required) .prg will be used to count bytes for the size limit.
win-win? :)
edit: I forgot to add, what an awesome compo this was!
thanks for organizing and participating, many gems found :) |
