Live Coding Compo Framework
category: code [glöplog]
skomp: yes we are aware of that noise texture problem. Probably we will not allow it in the end. We were thinking about 8 textures, where 7 will be prepared by us, and 8th could be brought up by the competitor. But it's still under discussion, like you said, there could be a lot of exploits because of that. Shadertoy doesn't allow user textures, and this constraint makes people more creative.
8 textures, wow :D but you publish them beforehand, so we can take a look at them without having to implement coder for it and then decide that they are all useless for the current effect?
They will be shown just before the compo. The hosts will present them :) - so this will be a surprise - trust me :)
hehe, great :) then it's prolly best if they are just funny instead of useful :D
patch request :P while the wilhelm scream can be nice, i don't think listening to it in an endless loop improves the mental health :D
Code:
void liveCoding::bass_startCapture()
{
//bass_stopCapture();
const int freq = 44100;
const int channels = 2;
hRecord_ = BASS_RecordStart( freq, channels, BASS_SAMPLE_8BITS, 0, 0 );
if( !hRecord_ )
{
fprintf( stderr, "BASS_RecordStart failed! Err=%d\n", BASS_ErrorGetCode() );
}
//std::string file = liveCodingDir_ + "sine.wav";
//std::string file = liveCodingDir_ + "catzilla.ogg";
//std::string file = liveCodingDir_ + "wilhelm.wav";
/*if ( ! (hRecord_ = BASS_StreamCreateFile(FALSE,file.c_str(),0,0,BASS_SAMPLE_LOOP))
&& ! ( hRecord_ = BASS_MusicLoad(FALSE,file.c_str(),0,0,BASS_MUSIC_RAMP|BASS_SAMPLE_LOOP,1)))
{
assert( false );
return;
}
BASS_ChannelPlay(hRecord_,FALSE);*/
}It was just for testing :) - better write if FFT works fine
OMG, I just spent 10 minutes trying to figure out what that strange alarm was. I actually thought it was a bird stuck somewhere. But no, its just the Wilhelm scream playing through my wireless headphones at the other end of the room :(
bonzaj: it's perfect for me, works really well :)
The FFT history is really nice.
As for the Scintilla fork, I find the editor very convenient to use. It is also great to have the editor and the effect in the same window, although maybe they should be in separate places rather than superimposed on each other, so you can see the effect unobscured without hiding the editor.
Of course, for the compo, it doesn't matter so much what is on the contestants' screens, I think (apart from the editor, of course). The important thing is that the big screen shows both effect and editor contents at all times.
None of the frameworks survive a driver reset here.
As for the Scintilla fork, I find the editor very convenient to use. It is also great to have the editor and the effect in the same window, although maybe they should be in separate places rather than superimposed on each other, so you can see the effect unobscured without hiding the editor.
Of course, for the compo, it doesn't matter so much what is on the contestants' screens, I think (apart from the editor, of course). The important thing is that the big screen shows both effect and editor contents at all times.
None of the frameworks survive a driver reset here.
I won't be going to Revision, but I still have questions about this:
1) Is there a github/source code for this?
2) Does it support the same uniforms as glsl.heroku.com?
I ask because this looks like a nice tool for 1k/4k development.
1) Is there a github/source code for this?
2) Does it support the same uniforms as glsl.heroku.com?
I ask because this looks like a nice tool for 1k/4k development.
Blueberry:
You will have two monitors during compo. On first you will see the code, and on second the effect. Alternatively you can make a small always on top window and put it anywhere you want. I agree that having code on top of effect is disturbing. Probably we will end up having two options for contestants to choose from. Of course we will need to politely ask Gargaj to merge our last changes into github and fix the stuff with missing bass functionality and probably MIDI, wich is crucial.
You will have two monitors during compo. On first you will see the code, and on second the effect. Alternatively you can make a small always on top window and put it anywhere you want. I agree that having code on top of effect is disturbing. Probably we will end up having two options for contestants to choose from. Of course we will need to politely ask Gargaj to merge our last changes into github and fix the stuff with missing bass functionality and probably MIDI, wich is crucial.
I already added the MIDI+BASS stuff.
Gargaj: good! and did you update the FFT from v0_91 ? If yes, then we can say that we are ready to go :)
there is a little something wrong in the midi.cpp of gargajs tool i guess...
Code:
1> midi.cpp
1>..\liveCoding\midi.cpp(40): error C2664: 'strcmp' : cannot convert parameter 1 from 'WCHAR [32]' to 'const char *'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>
1>Build FAILED.
1>skomp: just pushed a fix up for that - bonzaj's code want TCHAR-compatible ;)
now i'll merge to 0.91
now i'll merge to 0.91
Merge done, get the binary here: https://github.com/Gargaj/ScintillaGL/releases
after some quick testing on the livecoding-machines:
- can't write { } brackets on german keyboard layout
- ctrl+z / ctrl+y is switched on german keyboard layout
- umlauts are invisible
other than that: looking good. :)
- can't write { } brackets on german keyboard layout
- ctrl+z / ctrl+y is switched on german keyboard layout
- umlauts are invisible
other than that: looking good. :)
I couldn't make it run in my machine :(
I think showing code on top of the effect is disturbing for the programmer, but it's important for the audience who's watching the compo. I think the solution is to have the programmer and the audience see different things. The code could work in an editor and a viewer which are separated from each other, as in this tool or Shadertoy, BUT then there's a THIRD window that the coder doesn't necessarily see, which is there only for show purposes. This show windows does overlay the effect and the code, in probably very fancy ways such as as pulsating text (where the cursor is active and so on, to make it easier for the audience to follow the coding). Since the coder doesn't work in this Show-Window, things can go really crazy and spectacular (what you need for a great show), while the coder is really doing his/her job in a nicely, clean and relaxed environment (that the audience doesn't see).
For this Siggraph we are thinking of organizing a live coding tournament in a big format. The first idea was to extend my live coding tool, or extend Shadertoy with fancyness, but if this one gets the features we need, I'd prefer we use this one indeed.
As for my failure to use the tool, I'm using VS2012. The preview windows opened, VS opened the project successfully, but I failed at compiling one shader and sending it to the preview window :( Any help is welcome, I feel I'm just missing something stupid like pressing some key.
I think showing code on top of the effect is disturbing for the programmer, but it's important for the audience who's watching the compo. I think the solution is to have the programmer and the audience see different things. The code could work in an editor and a viewer which are separated from each other, as in this tool or Shadertoy, BUT then there's a THIRD window that the coder doesn't necessarily see, which is there only for show purposes. This show windows does overlay the effect and the code, in probably very fancy ways such as as pulsating text (where the cursor is active and so on, to make it easier for the audience to follow the coding). Since the coder doesn't work in this Show-Window, things can go really crazy and spectacular (what you need for a great show), while the coder is really doing his/her job in a nicely, clean and relaxed environment (that the audience doesn't see).
For this Siggraph we are thinking of organizing a live coding tournament in a big format. The first idea was to extend my live coding tool, or extend Shadertoy with fancyness, but if this one gets the features we need, I'd prefer we use this one indeed.
As for my failure to use the tool, I'm using VS2012. The preview windows opened, VS opened the project successfully, but I failed at compiling one shader and sending it to the preview window :( Any help is welcome, I feel I'm just missing something stupid like pressing some key.
iq: is that the liveCoding tool or the ScintillaGL one?
Oh, for the working problems that was Plastic's liveCoding. ScintillaGL works fine!
For using somebody else's tool for the tournament, I'd use any of them, whichever is better suited! This is how far I went myself: http://www.youtube.com/watch?v=y8aL4Cnb9m4. But if I had to make a new one I'd start it from scratch, which makes not that much sense if you are making one already! But yeah, does anybody else think that having the coder's view (editor and viewer separated) and audience's view (overlapping/sliding/facing effect+code+interaction+whatnot) separated makes sense? This fancy audience's view could be a pluginizable bit so different partys/events could pick how visually fancy they want the show to be.
For using somebody else's tool for the tournament, I'd use any of them, whichever is better suited! This is how far I went myself: http://www.youtube.com/watch?v=y8aL4Cnb9m4. But if I had to make a new one I'd start it from scratch, which makes not that much sense if you are making one already! But yeah, does anybody else think that having the coder's view (editor and viewer separated) and audience's view (overlapping/sliding/facing effect+code+interaction+whatnot) separated makes sense? This fancy audience's view could be a pluginizable bit so different partys/events could pick how visually fancy they want the show to be.
iq: partly agreed, but there needs to be moments when the code isn't obscuring the effect so that everyone can get a good look at it, so it's probably best if the coder is "forced" to do so every now and then.
Iq: this exactly for we did at WeCan. 3 outputs for each contestant:
1. VS view
2. clean preview
3. preview with fancy code overlay
---
setup was big since we displayed 4 outputs on big projector and two big LCD's over contestants heads (we had 4 hdmi splitters, and a professional video mixer to do it) but it was marvelous.
I saw that people actually did not care about the effect + code overlay. They preferred the clean version over contestants heads. But probably it was like that because of the whole party place.
The problem with that setup was GPU performance - it was cut in half, but probably we could do it better.
The current version is much better since it does not block the VS editor, so you can still edit your code while previous version is compiling.
Two versions will be available at the party place, so you will be able to choose the one you like. Or organizers will check which one behaves better with the audience.
1. VS view
2. clean preview
3. preview with fancy code overlay
---
setup was big since we displayed 4 outputs on big projector and two big LCD's over contestants heads (we had 4 hdmi splitters, and a professional video mixer to do it) but it was marvelous.
I saw that people actually did not care about the effect + code overlay. They preferred the clean version over contestants heads. But probably it was like that because of the whole party place.
The problem with that setup was GPU performance - it was cut in half, but probably we could do it better.
The current version is much better since it does not block the VS editor, so you can still edit your code while previous version is compiling.
Two versions will be available at the party place, so you will be able to choose the one you like. Or organizers will check which one behaves better with the audience.
Super interesting thread!
In general, I think that the ultimate goal of such a framework is to make things interesting for the audience and let's face it, looking at coding-in-progress isn't exactly a roller coaster ride...
And another thing, something I noticed in IQ's video, living coding is not about: "code for an hour and show us what you got", it's more about the process thinking on effect, writing code, compiling it, debugging it, present it, tweak it, and starting to work on a new one. The only really interesting parts are the "present it" and "tweak it", the rest is really boring things like long coding periods, compiler nagging and rendering of "debug views".
So I think of the following:
first, I tend to agree with iq about the 3 views, only with a little twist, I think that the 3rd view should be VJ onto the big screen by the organizers. This way, you can always make sure that there is something interesting going on screen.
never really done live coding, but I think that often, the coder experiences "this is cool" moments, and those are the moments you want to display on the bigscreen. so if the code can somehow "commit a this-is-cool version" to the VJ, the VJ might have a list of all "this is cool" moments of each coder and can VJ between them.
To sum things up, I think that coder should be working on something very similar to ShaderToy (continues compiling be nice though), it should have a "this-is-cool" button to submit things to VJs. The VJs should be able to select between hide/show overlay, live or committed version, single coder or split view etc, etc...
minor detail: to simplify the setup, I don't think that the VJ station should process video from the coder stations, a TCP/UDP streaming of the code and rendering on VJ station would be simpler.
as I said, never really did live coding, so I might be talking rubbish here...
In general, I think that the ultimate goal of such a framework is to make things interesting for the audience and let's face it, looking at coding-in-progress isn't exactly a roller coaster ride...
And another thing, something I noticed in IQ's video, living coding is not about: "code for an hour and show us what you got", it's more about the process thinking on effect, writing code, compiling it, debugging it, present it, tweak it, and starting to work on a new one. The only really interesting parts are the "present it" and "tweak it", the rest is really boring things like long coding periods, compiler nagging and rendering of "debug views".
So I think of the following:
first, I tend to agree with iq about the 3 views, only with a little twist, I think that the 3rd view should be VJ onto the big screen by the organizers. This way, you can always make sure that there is something interesting going on screen.
never really done live coding, but I think that often, the coder experiences "this is cool" moments, and those are the moments you want to display on the bigscreen. so if the code can somehow "commit a this-is-cool version" to the VJ, the VJ might have a list of all "this is cool" moments of each coder and can VJ between them.
To sum things up, I think that coder should be working on something very similar to ShaderToy (continues compiling be nice though), it should have a "this-is-cool" button to submit things to VJs. The VJs should be able to select between hide/show overlay, live or committed version, single coder or split view etc, etc...
minor detail: to simplify the setup, I don't think that the VJ station should process video from the coder stations, a TCP/UDP streaming of the code and rendering on VJ station would be simpler.
as I said, never really did live coding, so I might be talking rubbish here...
I'm with TLM on this one - the actual coding aspect is pretty dull to behold most of the time, sorry. Doing a "handoff" to someone who can tweak and "use" the effects would be great.
he he gloom - ask Hyde if he liked what we had on WeCan. Remember that we had 20 minutes rounds! On revision there will be 25 minutes, but after the first rounds, the organizers may modify that. The dull moments can be easily modified by the coder, by just showing the inbetween steps, and not trying to code the whole thing at once. Because we had an audience voting, then bringing a dull moments to audience resulted in no votes. It really works if it:
1. fast paced (max 20 minutes - can be reduced to 15, 10 minutes) - the type of discussion (you can't do anything interesting in that time) is wrong. You can :).
2. commentary - there need's to be sport's type commentary going on all the time. (like they do with games esports). there need to be an expert trying to figure out what we are going to see, or what we have seen, and a typical show man - like okkie :) to handle the crowd
3. the DJ's shouldn't have too much control over the visuals. It's because they can disturb the coder, if he's looking for a bug or something.
4. the coders are as good tweakers (even better) than VJ's. mostly because they know what they code. Look at the shadertoy page and tell all the coders there that they can't tweak. They can :).
1. fast paced (max 20 minutes - can be reduced to 15, 10 minutes) - the type of discussion (you can't do anything interesting in that time) is wrong. You can :).
2. commentary - there need's to be sport's type commentary going on all the time. (like they do with games esports). there need to be an expert trying to figure out what we are going to see, or what we have seen, and a typical show man - like okkie :) to handle the crowd
3. the DJ's shouldn't have too much control over the visuals. It's because they can disturb the coder, if he's looking for a bug or something.
4. the coders are as good tweakers (even better) than VJ's. mostly because they know what they code. Look at the shadertoy page and tell all the coders there that they can't tweak. They can :).