pouët.net

kb: useful, thanks!

I hadn't thought much about sound. It's interesting that audio tends to be a lot closer to realtime (or actually realtime) than graphics. Is there no benefit to having unlimited compute time for audio then? (Obviously there are downsides when editing :)

I think you're right on how to do it though: 4k exe to generate visuals, render to video, hand it to musician, wait for mp3. (Or the other way round of course.)

Hardy: making a demo with no way of jumping to a particular time.. urgh :D I realised fast that wasn't workable when i first made a demo, and made sure i could a. play from a particular point and b. loop a particular section while tweaking shit. Without that I think i'd go crazy :D

sure, i went the way of exporting 4klang-tracks with offsets...just cutting the first 20 patterns, so i could jump in at effect6, if you know what i mean ;) but wasnt kewl to work like that at all. now that i tweaked my 4klang its all just scratchable, played back by time_at ;) i love it!
and: i went crazy a lot when i was producing 4ks without even multiple_exporting the soundtrack at different tracks_as_start. (happened a lot, when i made some lastMinute_4k, as most of my 4ks were lastMinute! But felt interesting first aswell, i got that amiga-demo-coding-feeling back, i had when i was 14, back in 1992!)

No, unlimited compute time for audio doesn't make too much sense. Of course you can do way more stuff with it, but CPU time isn't the biggest problem that 4K audio has. This biggest problem is that audio is complex, sound as well as composition wise.

Sounds are made of lots of small building blocks with elaborate custom wiring between them, and each of these building blocks themselves can be coded either small but cheap, or good but complex. Both algorithms and the wiring/parameters take space, and throwing 100 things at the problem in non-realtime vs 1 thing in realtime doesn't really make it better or smaller. Only exception would be very complex physical models but these also have a crapton of hand tweaked and only barely compressible constants attached if you want them to sound like anything nontrivial.

Also, post processing is important. Easy to do for graphics, but for sound you really need a lot of different effects to get to a polished results. Again, bad for size, and this won't change if you drop the realtime requirement.

And as far as compositions are concerned... well. Somebody correct me if my knowledge of modern classical music is too weak to say this, but: I've yet to hear an algorithmically generated song that actually sounds good. And until humanity has fully cracked the math behind music this means that every single note needs to be put into the timeline manually. And this, too, takes a lot of memory. For most 4ks this means: Compose one pattern, and then copy-paste and delete your way to a complete "song" (same for most entries in music compos at demo parties, but I digress :D). And if there's still space, put in a few breaks. Yaaaay... NOT. And again, more/smarter/slower code won't help you.

Now, explaining how much work it is to edit a song without being able to listen to it during the process is way too much text and should also be evident. ;)

BTW two know examples of procedural animation in 4k by iq.

slisesix animation

leizex animation

And also..

ixaleno animation

pathtracing in the GPU

Also more here iq youtube channel

Is nice to see that many procedural graphics can be direct converted into a simple animations.

A procedural animation does not need to be a several minutes demo. One cool thing is probably to make a short animation 1080p60fps loop.

kb_, I think you are so right about mzk. At the same time, I personally have absolutely no problem with making a 16k procedural gfx category (or 32 or even limitless for the matter - as long as it's procedural it's fun, i think, although not easy to detect cheats when data is > 128k or so). Perhaps both 64k procedural video entries would work, or we can let the author decide.

My only fear is that 4k/64k videos will just be a 4k/64k realtime intro rendered with massive screen and time supersampling to bring quality, but nothing fundamentally different than an intro...

you can be sure sphere-tracing would still be the preferred technique then ;) (just imagine yourself having to re-run your 4k_code every 20 hours to see if it generated what you thought it should after altering just one line of code!)

kb: I guess there's the case where you make complex/slow instruments and use them as samples, composing in realtime. And there's cdak, which has pretty awesome audio but not much of a tune. I'm sure there's somebody out there up for the challenge of doing amazing non-realtime audio in 4k... but probably not so many of those people.

So 4k visuals + separate audio makes more sense for most I guess, especially as we don't want to have absolute killer visuals with a tune that sounds like bad midi because there's no space left. If it's 4k including good audio and it's entered into the wild comp it's just going to have more impact.

Paulo: also see unc's videos on vimeo - i doubt they're 4k, but it's interesting to see where the techniques used in cdak can go with a bit more rendering time :)

well, demosceners are clever, they will find out by themselves how to develop techniques for not having to re render everything. rendering every other frame, low res, less GI samples, less polys... most 20 hours render that i know off render realtime as soon as you relax aliasing, motion blur and raytracing samples. actually, i think most videos will be, as i said, glorified regular realtime intros. so i totally expect authoring and content creation to happen in realtime or at interactive rates. i don't think anybody will have to wait 20 hours but for the final video...

also i dont think (what some of you might be having in mind) going cpu-only again would make things any better...depending on cores_usable and cpu-model_at_all you are going to have strange results in comparision again...
...dont think about existing softSynths (as in 4klang, using a second core,if wanted, for music-precalc while the intro is running already!) at all, which use up like 30% of the nowadays cpus already at all right now ;)

internet-police to the rescue, that hardy-dude messed up with english language! go, get him!
sorry for my bad sentences, i am getting sloppy with my english lately! sorry!

psonice: Precalcing and using samples is bigger than realtime ;) And yes, cdak is the very notable exception that proves the rule. Because as brilliant as it is - do you want every 4K anim to have only ambient sound scapes or whatever solo instrument there is as a soundtrack?

cdak aint brilliant at all, we all know it! its just the same approach we all abuse, sphere-tracing with what kb_loves_that_much: offsets! just the music in the party-version was no music but ambient! thats all, folks!

just only one scene makes place for a texture ofcoz! ;)
the metaballs-scene is just luck! ;)

cdak rulez hard.

this is the same, just without extra-offsets, also calculatable by just using a better algorhitm! ;)
shameless cdak-tech-ripoff
i still love it, eventho i did it myself! but who said, you arent allowed to love your own shit? ;)

also without applied texture, but i didnt intend to make cdak 0.3 anyway!

i don't really think that sound is a problem for 4ks, but the music is - even if you can make alias-free oscillators and tune your filters or whatever, you still don't have any space for the score, so it have to be one pattern of corny beat. and that kills anything you've got to show. =(

and as you hardly can beat brothomstates in making a perfect tune with couple of sustained notes, i'm personally still interested in designing a 64k soundsystem way more than 4k one.