Live Coding Compo Framework
category: code [glöplog]
Code:
const float PI = 3.14159;That's way too little precision. At least "3.14159265" should be used for GPU highp float/trigonometry.
you kidding?
Who needs to memorize PI?
Code:
static float PI = acos(-1);Who needs to memorize PI?
Frankly that should be a compiler-provided constant but zomg.
You mean #define _USE_MATH_DEFINES, #include <cmath>? :) (non-standard but works on all relevant compilers)
Does it work in the GLSL compiler?
Oh right, of course the only file showing up in GitHub's superior repository search for that specific constant was a C++ file...
xTr1m wins, although for GLSL that would be "const float PI = acos(-1);" (not "static").
[smartass mode on]
The proper way to support PI or any other irrational constants e.g. sqrt(2) would be via symbolic const-folding, which is AFAIK not supported by any compiler so far ;)
[smartass mode off]
[smartass mode on]
The proper way to support PI or any other irrational constants e.g. sqrt(2) would be via symbolic const-folding, which is AFAIK not supported by any compiler so far ;)
[smartass mode off]
@kb: Is the NDI SDK actually supposed to be available for everyone now? Last time I checked, they wanted you to sign up before you got the URL (and explicitly asked you not to share it).
NDI is pretty nice, although it's just a tweaked MPEG-2 intraframe. Tons of security issues, though, so don't run it on unfriendly networks. :-)
NDI is pretty nice, although it's just a tweaked MPEG-2 intraframe. Tons of security issues, though, so don't run it on unfriendly networks. :-)
The link kb posted links straight to the SDK installer, no signup needed; as far as I can remember it's under the MIT license now.
@Gargaj: The _headers_ are under the MIT license. The SDK itself is not. It has its own license agreement, e.g. requiring you to report any bugs you find to NewTek, not pass on the documentation to others, and not to modify the SDK. And of course, it doesn't come with source code, so if you'd like to use it on another platform than they compiled for (e.g. the ARM binaries don't contain a decoder, only an encoder—and the 32-bit Linux binaries don't really contain codec code at all), you're out of luck.
But I see that the “sign up and apply and we'll see about that manually” has been replaced with a “insert your name here and you'll get to download” form, so I guess it's been more generally opened up.
But I see that the “sign up and apply and we'll see about that manually” has been replaced with a “insert your name here and you'll get to download” form, so I guess it's been more generally opened up.
Quote:
xTr1m wins, although for GLSL that would be "const float PI = acos(-1);" (not "static").
True. I just quoted my HLSL code. ;)
// todo;fix later... *meh*
#define PI 3
#define PI 3
Yeah, Sesse is right unfortunately. Could you remove the link or change it to ndi.newtek.cmo please?
What link?
Quote:
The _headers_ are under the MIT license.
For practical purposes, that's sufficient, isn't it?
I have no idea what any of us is talking about.
I don't mind any of the "security issues" tho - it's clearly designed to run at LAN level where people do hae control over who gets to access what. On the contrary - some protocols are now so shut they flat out don't work in certain circumstances anymore - try WebRTC in a local network w/o internet connection for example.
I don't mind any of the "security issues" tho - it's clearly designed to run at LAN level where people do hae control over who gets to access what. On the contrary - some protocols are now so shut they flat out don't work in certain circumstances anymore - try WebRTC in a local network w/o internet connection for example.
Gargaj: Depends on sufficient for what. MITed headers is sufficient for linking most OSS software against it (GPL-ed software is a notable exception). It's not sufficient for distributing any other part of the SDK.
kb: Yes, like I said, don't run it on an unfriendly network. :-) (Which also means you'll need to NAT/firewall it away from the Internet.) It will happily crash if it gets e.g. an unexpected version number in the hello packet, not to mention all the buffer overflows in the decoder. If it's walled off and your network doesn't randomly corrupt packets (rather unlikely), then everything should be fine.
kb: Yes, like I said, don't run it on an unfriendly network. :-) (Which also means you'll need to NAT/firewall it away from the Internet.) It will happily crash if it gets e.g. an unexpected version number in the hello packet, not to mention all the buffer overflows in the decoder. If it's walled off and your network doesn't randomly corrupt packets (rather unlikely), then everything should be fine.
Hey Gargaj, I love the tool.
Scintilla has nice bracket match highlighting; I'm not sure if that exists in ScintillaGL (and I'm lame for not checking first), but if it does could it please be enabled? Would help a lot with those frantic oneliners :)
Scintilla has nice bracket match highlighting; I'm not sure if that exists in ScintillaGL (and I'm lame for not checking first), but if it does could it please be enabled? Would help a lot with those frantic oneliners :)
It should be enabled (STYLE_BRACELIGHT), if not, I'll take a look.
Gargaj: have you thought about adding support for MIDI beat clock? It could facilitate a bit better music sync, in addition to the current frequency band peak level metering thing. The beat clock messages could come from e.g. Ableton Live or Traktor, which are pretty good at syncing to any DJ stuff.
I'm thinking, the beat clock could be transformed into a uniform float value that's 1.0 on the beat, and goes down to about 0.
I'm thinking, the beat clock could be transformed into a uniform float value that's 1.0 on the beat, and goes down to about 0.
Haven't considered it no - pull requests are welcome :D
I have also been pondering a beat clock as a very useful addition. For full flexibility, this should be a smoothly increasing value which hits an integer on every beat.
Ideally, the beat detection could be built into Bonzomatic so it doesn't depend on external software to deliver the signal. But if it's easy (and reliable) to set up using an external sync generator, that would be fine as well, of course.
Ideally, the beat detection could be built into Bonzomatic so it doesn't depend on external software to deliver the signal. But if it's easy (and reliable) to set up using an external sync generator, that would be fine as well, of course.
Will Bonzomatic be used for Revision 2018? That's in a month and if Bonzomatic is to be used again I think it would be a great time to merge the patch-1 branch into master, so that the new features and improvements (including my own) can be seen in next months compo! :)
