|
549NOTES
[nfo]
|
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||||||
|
popularity : 55% |
|||||||||||||
alltime top: #10899 |
|
|||||||||||||
|
||||||||||||||
added on the 2019-02-02 23:49:32 by TomCatAbaddon  |
||||||||||||||
popularity helper
comments
neat! ;] much notes!
rulez added on the 2019-02-02 23:55:49 by nula 
great!
great!
Bach was a genius, too. ;-)
noteworthy
unbelievable!!
Cool!
неразборчивый почерк (:
woah!
...relaxing music for a sunday morning :-)
Coool music tinytro
At first 549 notes sounded really impressive, then i realized that it repeats twice, which makes it ~225, then i realized from an 8 notes block, 5 are unique, which makes it ~140, and then using 4 or 5 bits instead of 8 per note makes it something from 70 to 90 bytes. Still, all the unpacking and the graphics have to be done, so thumbs for idea and effort =) Shameless selfad: I did "Symphony" in 128b, that's maybe why my jaw is not completely dropping to the floor ;)
@Optimus, you spotted the concept, but your calculation is not correct. The song have actually 197 notes: the first part is effective 512 notes, can be stored as 160 thanks to repetitions, the last part is 32+5, have no repeating patterns.
This 197 notes are compressed, stored in 114 bytes. The player is 123 bytes long, the visual occupies only 19 bytes, including the screen mode initialization. (Concept and data compressor was my part, crazy optimization is done by TomCat, and original song is written by J. S. Bach, some time ago.)
Stay tuned, we are working on a pretty long presentation, which will contains really lot of details, not only about the code itself but the project: failed concepts, data compression, optimization, automatic tests(!) and so on. This presentation is not a usual marketing bullshit, it lack of animations and using only two fonts (one for text, one for code), but it contains a fair amount of 8086 assembly code. We still don't know where will be it released, but we will publish the slides as well (PDF format).
Source code will be also available, I have some tasks with cleaning up the repository, then I will put it on GitHub.
We knew that this demo is not a bombastic instant success, but I am very happy that so many scene dudes appreciate our effort.
This 197 notes are compressed, stored in 114 bytes. The player is 123 bytes long, the visual occupies only 19 bytes, including the screen mode initialization. (Concept and data compressor was my part, crazy optimization is done by TomCat, and original song is written by J. S. Bach, some time ago.)
Stay tuned, we are working on a pretty long presentation, which will contains really lot of details, not only about the code itself but the project: failed concepts, data compression, optimization, automatic tests(!) and so on. This presentation is not a usual marketing bullshit, it lack of animations and using only two fonts (one for text, one for code), but it contains a fair amount of 8086 assembly code. We still don't know where will be it released, but we will publish the slides as well (PDF format).
Source code will be also available, I have some tasks with cleaning up the repository, then I will put it on GitHub.
We knew that this demo is not a bombastic instant success, but I am very happy that so many scene dudes appreciate our effort.
Nice!
Nice!
i swear to god..
A Bach MIDI tune in a small MS-DOS exe
Bach's composition is pretty.
The rest feels underwhelming since I made a similar calculation as Hellmood in my head and the note data really shouldn't be very large at all. The name of the production would indicate that to be the main selling point though.
The rest feels underwhelming since I made a similar calculation as Hellmood in my head and the note data really shouldn't be very large at all. The name of the production would indicate that to be the main selling point though.
The note data is 197 notes, plus it requires tempo change 2 times. If you just simply store one note in one byte, you have 59 bytes for: MIDI init and note play, repeat lines combined with repeating line endings, switch between repeating and non-repeating parts (ending 32 + 5 notes), 2x tempo changes, and some visual. Using compression, the data is 114 bytes, some of the extra bytes spent on decompression, but overall gained some bytes for code.
Yes, "549 notes which is really 197 data items, but it's still not trivial to implement in 256-byte because combined repeating requires some code" would be more accurate, but less catchy name.
We'll explain everything about this intro bit by bit in our presentation.
Yes, "549 notes which is really 197 data items, but it's still not trivial to implement in 256-byte because combined repeating requires some code" would be more accurate, but less catchy name.
We'll explain everything about this intro bit by bit in our presentation.
I know how noby feels about quantity and quality, and it's ok. Sometimes our main goal is to max the quality, like the best looking pic in 256b, Sometimes our main goal is to max the quantity, like here the longest music in 256b. Both of them good challenge and fun.
One more thing: exactly reproducing something was somewhat different what we used to do when we optimize stuff contains data. There were no such option that, say, skip the end part because it's not compressable, and improve visual instead, not even change a note in order to gain one byte. Bach would have been angry for such things.
Classic
Cool!
great
Cool!
nice!
It's perfect
Very relaxing and hypnotic in a positive way.
Great pastel colors for this delicate music.
Just great.
Köszi fiuk.
Great pastel colors for this delicate music.
Just great.
Köszi fiuk.
Source, tool source, presentation (PDF) etc. available on GitHub: https://github.com/ern0/549notes
yes
lists containing this prod
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !