| --- Log opened Fri Aug 08 00:00:20 2008 |
| 00:09 | | crem [~moo@Nightstar-28703.adsl.mgts.by] has quit [Ping Timeout] |
| 00:24 | | crem [~moo@Nightstar-28703.adsl.mgts.by] has joined #code |
| 00:29 | | crem [~moo@Nightstar-28703.adsl.mgts.by] has quit [Connection reset by peer] |
| 00:29 | | crem [~moo@Nightstar-28703.adsl.mgts.by] has joined #code |
| 00:41 | <+Consul> | You know, I'm kinda liking the idea of our preset files actually being Lua scripts. Just load and run, and it loads itself. |
| 00:41 | <+Consul> | It could also load additional functions that would be used by the synth engine as part of the preset. |
| 01:00 | <@McMartin> | You'll need some performance checks, of course, but remember that efficiency isn't an issue until you can prove you don't have it. |
| 01:01 | <@McMartin> | And if it's just config, you're golden |
| 01:01 | <+Consul> | Well, I have ideas beyond that, but we'll see what is and isn't possible. |
| 01:02 | <+Consul> | The scripting will be mostly event-based. |
| 01:02 | <+Consul> | Anyway, gotta go, heading off to get a plant... |
| 01:08 | | gnolam [lenin@Nightstar-2037.A163.cust.bahnhof.se] has quit [Quit: Z?] |
| 01:14 | | Derakon[AFK] is now known as Derakon |
| 01:20 | | crem [~moo@Nightstar-28703.adsl.mgts.by] has quit [Ping Timeout] |
| 01:45 | <+Consul> | And we are now the proud owners of an aloe vera plant, finally. |
| 01:47 | <@AFKSkull> | yay |
| 01:47 | <+Consul> | Hehe |
| 01:47 | <+Consul> | Too bad it won't make me a better coder. |
| 01:49 | <@AFKSkull> | it will sure come in handy if you burn yurself though |
| 01:50 | <+Consul> | Indeed. |
| 01:50 | <+Consul> | Which happens every so often, as an avid cook. |
| 01:50 | <@Derakon> | Heh. |
| 01:50 | <@Derakon> | Don't fry without a shirt on~ |
| 01:50 | <+Consul> | I don't. |
| 01:50 | <+Consul> | Never fry bacon naked. |
| 01:50 | <+Consul> | I learned that first-hand. |
| 01:50 | <+Consul> | And now that I've planted that image in your heads... |
| 01:52 | <@Derakon> | You call that a mental image? |
| 01:52 | <+Consul> | You would if you saw a 330-pound man naked. :-P |
| 01:52 | <@Derakon> | I've seen worse. |
| 01:52 | <+Consul> | To be fair, though, I wasn't that big when I learned this object lesson. I was actually thin enough to be attractive to ladies. |
| 01:53 | <+Consul> | Can a Lua script modify itself? |
| 01:53 | <@Derakon> | I wouldn't be surprised, but you might have to reload it after. Talk to TF; he's the Lua guru. |
| 01:54 | <@ToxicFrog> | Can a Lua script load more Lua code at runtime, and call it? Yes. |
| 01:54 | <@ToxicFrog> | Can a Lua function replace itself? Yes. |
| 01:54 | <@ToxicFrog> | Can these facilities be used to create self-modifying lua code? Yes. |
| 01:55 | <+Consul> | The idea is, if someone changes their preset, then saves the changes... |
| 01:55 | <@ToxicFrog> | Can you edit the program AST directly and see changes immediately reflected? No, it's compiled to bytecode and the IR is not available for manipulation. |
| 01:55 | <+Consul> | So, it would need to reload after saving. |
| 01:55 | <@ToxicFrog> | Ummm |
| 01:55 | <@ToxicFrog> | Not really |
| 01:55 | <@ToxicFrog> | The preset is a bunch of data and code stored in Lua space, right? |
| 01:56 | <@ToxicFrog> | When they change their preset, those changes are immediately reflected in Lua, because that's where it's stored |
| 01:56 | <+Consul> | Well, my idea is that the Lua script itself *is* the preset. |
| 01:56 | <@ToxicFrog> | When they save it, the contents of the preset structure are saved to disk |
| 01:56 | <@Derakon> | So if the preset is a table, then you load the file into memory, thereby getting the table. |
| 01:56 | <+Consul> | Because that way, Lua functions can be part of the preset, and part of the synth. |
| 01:56 | <@ToxicFrog> | No, the lua script is how the preset is stored on disk. |
| 01:56 | <@Derakon> | When the user updates their presets, you update the table. |
| 01:56 | <@Derakon> | When you save the presets, the table is rewritten to disk. |
| 01:56 | <@ToxicFrog> | Once loaded into memory, it's not "a script", it's "a collection of data and code, which can be read, write, and called" |
| 01:57 | <@ToxicFrog> | *written |
| 01:57 | <+Consul> | Ah, I think I see what you're saying. |
| 01:57 | <@ToxicFrog> | The C equivalent would be, say, you have a file consisting of a list of numbers seperated by , |
| 01:57 | <@ToxicFrog> | On disk, it's a list of comma seperated values |
| 01:57 | <@Derakon> | In memory, it's an array. |
| 01:58 | <@ToxicFrog> | But you'd probably load it into an array to actually use it, and changes made are reflected immediately in the array |
| 01:58 | <+Consul> | Okay, no problem there... |
| 01:59 | <+Consul> | I'm trying to figure out how to get my idea across... |
| 01:59 | <+Consul> | Although now that I think about it, it might not be such a good idea. |
| 01:59 | <@ToxicFrog> | One thing to keep in mind here is that in Lua, functions are first-class and can be created at runtime. |
| 01:59 | <@Derakon> | If you want to put actual code into the presets, well, presumably your users aren't going to be writing Lua scripts in their UI. |
| 01:59 | <@Derakon> | So what you'd save is the parameters used to generate the Lua code, not the code itself. |
| 02:00 | <+Consul> | Derakon: Yeah, that's it! The presets are actual code. |
| 02:00 | <@ToxicFrog> | Well |
| 02:00 | <@ToxicFrog> | You would save the parameters as code |
| 02:00 | <+Consul> | That was the idea, anyway. |
| 02:00 | <@ToxicFrog> | Because that makes it totally trivial to load |
| 02:00 | <@Derakon> | Right, TF... |
| 02:00 | <+Consul> | But, in the end... |
| 02:00 | <@ToxicFrog> | But you would save it as code that recalls the parameters of the widget used to create the underlying function |
| 02:00 | <@ToxicFrog> | You wouldn't dump the function's bytecode directly |
| 02:01 | <+Consul> | It would probably be best if Lua functions that are actually part of the preset to be stored separately. That way, they can be used as part of other presets. |
| 02:01 | <@ToxicFrog> | (even if it's a user-defined function, you'd probably want to dump source so that you can edit it after a save/load) |
| 02:01 | <@Derakon> | So for example, instead of writing to disk "function f(a) {return a + 5}", you'd write "local x = 5" and from that generate the function that adds x to its argument. |
| 02:01 | <+Consul> | From the GUI standpoint, my dream is for people to right-click on a control (knob, or slider, or whatever other widget), and be able to associate a function with it. |
| 02:02 | <@ToxicFrog> | Nod |
| 02:02 | <@ToxicFrog> | What I'm seeing this as is that it gives you a list of pre-defined functions, which can be tuned |
| 02:02 | <@ToxicFrog> | Eg, average, linear interpolation, sine, etc |
| 02:02 | <+Consul> | If these Lua scripts can access the engine, and the incoming OSC control data, we could make a pretty powerful sampler. |
| 02:03 | <@ToxicFrog> | And a "user defined" box that lets you type in an expression for creating your own functions |
| 02:03 | <+Consul> | Oooh, ToxicFrog is right on... |
| 02:03 | <@ToxicFrog> | If you use a pre-defined, it gets saved to disk as a thingy that remembers which predefined function you used, and what its parameters were |
| 02:03 | <@ToxicFrog> | If you enter your own, it gets saved to disk as source code, so you can edit it later |
| 02:04 | <+Consul> | But as a separate script, rather than part of the preset. |
| 02:04 | <+Consul> | Code reuse and all that. :-) |
| 02:04 | <@ToxicFrog> | You mean the canned functions, or the user-defined ones? |
| 02:05 | <+Consul> | Or maybe we could give the option of saving within or outside the preset file. |
| 02:05 | <+Consul> | User-defined. |
| 02:05 | <+Consul> | The canned ones will already be separate files. |
| 02:05 | <@ToxicFrog> | Hmm. Yeah, for that you could force the user to name it, and then save it seperately so it can be re-used |
| 02:05 | <+Consul> | Shipped with the program, so to speak. |
| 02:05 | <@Derakon> | I'd say instead you make the entire function aspect extendable. |
| 02:05 | <@ToxicFrog> | In which case it follows the same pattern as the canned ones |
| 02:05 | <@ToxicFrog> | Derakon: it isn't already? |
| 02:06 | <@Derakon> | So there'd be a control panel where you could add new scripts and assign them names and lists of arguments; you could use those functions later and associate them with sliders, etc. |
| 02:06 | <@Derakon> | Yeah, sounds like I just said what you said. |
| 02:06 | <@ToxicFrog> | Yeah, that's what we're describing |
| 02:07 | <@ToxicFrog> | So that gives it the same save/load behaviour as the canned scripts: it saves a marker that remembers the name of the function and the parameters of this instance, and the function itself is stored elsewhere |
| 02:07 | <@ToxicFrog> | All of them, of course, with source code for later editing |
| 02:07 | <+Consul> | I'm also imagining a system where parameters for script behavior can be set as keyframes, like we talked about before. |
| 02:08 | <@ToxicFrog> | Those are just simple start/end values, typically |
| 02:08 | <+Consul> | A beginning point, and end point, and then a controller that describes how to get from one to the other (timer, another controller, another script, etc.). |
| 02:08 | <@ToxicFrog> | Just another set of parameters to the function |
| 02:08 | <@ToxicFrog> | Right, my point is, we pretty much already have this in the design |
| 02:08 | <+Consul> | And then the "setting" of the key points would just be UI stuff. |
| 02:09 | <@ToxicFrog> | Anyways, the keyframes thing is entirely a UI aspect |
| 02:09 | <@ToxicFrog> | The actual code looks the same ither way |
| 02:12 | <+Consul> | So, our layers are: GUI <=> Lua <=> Core engine (which is dumb). |
| 02:13 | <+Consul> | Lua forming the basis for the "smart wrapper" we discussed earlier. |
| 02:13 | <@ToxicFrog> | Looks like it |
| 02:13 | <@ToxicFrog> | The core probably doesn't even need to know anything about lua |
| 02:13 | <+Consul> | Yeah, it's just function called at that point. |
| 02:14 | <@ToxicFrog> | But Lua needs to know about it - configures it, plugs in all the (notional) wires, and pulls the lever |
| 02:14 | <+Consul> | The core will likely be a directed graph, where N samples of output are asked for (64, say), and the parameters controlling the behavior of each node in the graph is a signal like any other. |
| 02:15 | <+Consul> | So, Lua will need to be able to operate at the sample rate, but it won't be intensive stuff, like convolution. |
| 02:15 | <+Consul> | Or... |
| 02:15 | <@ToxicFrog> | It should mostly be simple get/set of variables and small expression evaluation, I should think |
| 02:15 | <+Consul> | I suppose we *could* create a separate control rate, but I really wanted to avoid that. |
| 02:16 | <@ToxicFrog> | Don't worry about speed until you know it's not fast enough. |
| 02:16 | <+Consul> | Well, the thing is... Say we have a fram size of 64 samples... |
| 02:16 | <+Consul> | frame* |
| 02:16 | <+Consul> | So, we ask the core for output, and out comes a pointer to 64 samples of it. |
| 02:17 | <+Consul> | Now, let's say the preset involves modulating the filter cutoff, a very common thing to do in any synth. |
| 02:17 | <+Consul> | That modification to the filter's parameters can't be happening only once every 64 samples. You'd hear serious zipper noise. |
| 02:18 | <+Consul> | See where I'm getting at? |
| 02:19 | <@ToxicFrog> | It has to happen every sample, yes? |
| 02:19 | <+Consul> | Yes |
| 02:20 | <+Consul> | The Csound guys discovered once out of every 10 samples will also work well enough for most, but not all, applications (physical modeling is a notable one which needs sample granularity). |
| 02:21 | <@ToxicFrog> | So if you needed a seperate control rate it would be something like "every N samples"? |
| 02:21 | <@ToxicFrog> | That shouldn't be hard to add. Set it to 1 to start with. |
| 02:22 | <@ToxicFrog> | If it turns out to be a problem, easy enough to either make it configurable or look at optimizing the control systems. |
| 02:22 | <+Consul> | Well, the engine will treat everything as a "one sample per change" thing, no control rate. |
| 02:22 | <+Consul> | But that doesn't mean the Lua function has to recalculate itself that fast. |
| 02:23 | <+Consul> | It can just cache its output, then recalculate every N times/. |
| 02:26 | <+Consul> | The other point is that Lua doesn't have to be used on every single parameter. If it's not needed, just have the widget send out its value every sample and the core engine will use that. |
| 02:28 | <@ToxicFrog> | Yeah |
| 02:28 | <@ToxicFrog> | Constant values can easily be cached in c/space |
| 02:28 | <+Consul> | Until the widget is touched. |
| 02:28 | <+Consul> | I'm coming around to this whole idea. |
| 02:28 | <+Consul> | Now I just need to learn Lua. :-) |
| 02:28 | <+Consul> | I was having a hard enough time with C++... |
| 02:29 | <@ToxicFrog> | Lua is small and easy to learn. |
| 02:29 | <@ToxicFrog> | Also, unlike C++, you do not need to taff about with: |
| 02:30 | <@ToxicFrog> | - manual memory management |
| 02:30 | <@ToxicFrog> | - preprocessing and compiling |
| 02:30 | <@ToxicFrog> | - headers |
| 02:30 | <@ToxicFrog> | - explicit pointers |
| 02:31 | <@ToxicFrog> | (well, for the language itself, anyways; the C<->Lua interface, being written in C, will still involve such things.) |
| 02:31 | <@ToxicFrog> | It also has an interactive mode. You would not believe how much this helps. |
| 02:31 | <+Consul> | Yeah, I'll need to figure out how to best integrate it. |
| 02:32 | <@ToxicFrog> | First step is probably just the configuration system - the ability to save, load, and edit sets of key/value pairs. |
| 02:32 | <+Consul> | I guess there is a way to do it in C++, but I've been focusing on Lua itself first. |
| 02:33 | <@ToxicFrog> | Er |
| 02:33 | <@ToxicFrog> | You kind of have to do it in C++; if C++ and Lua are to be able to talk to each other, you need C++ code supporting this |
| 02:34 | <@ToxicFrog> | Or am I misunderstanding what you mean by "integrate" here? |
| 02:34 | <@ToxicFrog> | But yes - focusing on Lua first is wise, since trying to binding the language into your C++ code without knowing the language would probably go badly. |
| 02:34 | <+Consul> | I probably used the term wrong. |
| 02:34 | <+Consul> | But yes, what I mean is, make Lua available to my C++ program. |
| 02:34 | <@ToxicFrog> | Right. |
| 02:35 | <+Consul> | Which is reportedly more difficult than making it work within a C program. |
| 02:35 | <@ToxicFrog> | It is? |
| 02:35 | <@ToxicFrog> | #include <lua.hpp> |
| 02:35 | <@ToxicFrog> | ...use lua just as you would in a C program... |
| 02:35 | <+Consul> | Well, it could be the mailing list posts I hunted down didn't know what they were talking about... |
| 02:35 | <@ToxicFrog> | There, done. |
| 02:35 | <@ToxicFrog> | Or that they were talking about specific uses of it. |
| 02:36 | <@ToxicFrog> | For example, binding a C++ class to Lua, so that Lua can call methods on C++ objects of that class. |
| 02:36 | <+Consul> | That does sound familiar... |
| 02:36 | <@ToxicFrog> | That's harder than the C equivalent, since you can't export methods to lua directly (you lose this), you need to export statics which act as go-betweens. |
| 02:36 | | Attilla [~The.Attil@92.8.104.ns-27184] has quit [Ping Timeout] |
| 02:36 | <@ToxicFrog> | But not much harder. |
| 02:37 | <@ToxicFrog> | Basically: manipulating Lua from C++ is the same as in C; exporting of functions and simple data structures (arrays, structs) to Lua from C++ is the same as C. |
| 02:37 | <+Consul> | So, my engine code would need to be callable from Lua, right? |
| 02:37 | <@ToxicFrog> | Exporting C++ classes to Lua is not the same, what with C not having classes in the first place, and has some potential gotchas you need to be aware of. |
| 02:38 | <@ToxicFrog> | But once you understand how it actually works it's pretty easy. |
| 02:41 | <+Consul> | What does it mean to "export" a function or a class to Lua? Is that what you have to do for the function to be callable *by* Lua, or is there some other magic happening? |
| 02:41 | <@ToxicFrog> | The former, pretty much. Exporting a function to lua == making a C or C++ function callable by lua directly. |
| 02:42 | <@ToxicFrog> | Exporting a class implies more completeness: the ability for Lua to instantiate objects of that class and call methods on it (all of which call into C++ to do the actual work). |
| 02:42 | <+Consul> | Ah, so my core engine *would* have to do that, then. Meaning it does have to be Lua aware, right? |
| 02:42 | <@ToxicFrog> | (in some cases - like SupComm - they go so far as to permit Lua to subclass C++ classes) |
| 02:43 | <@ToxicFrog> | Umm. Something has to be Lua aware, it doesn't necessarily have to be the core engine. |
| 02:43 | | Attilla [~The.Attil@92.2.73.ns-20413] has joined #code |
| 02:43 | | mode/#code [+o Attilla] by ChanServ |
| 02:43 | <@ToxicFrog> | You could, for example, write a simple interface that bridges the two, exposing the necessary parts of the core to lua, while keeping the core itself pure C++ with no external depencencies. |
| 02:43 | <+Consul> | Oh, I could export an object that simply passes calls on to the core engine. |
| 02:44 | <@ToxicFrog> | Exactly. |
| 02:44 | <@ToxicFrog> | That's all you'd be doing in any case, really |
| 02:44 | <+Consul> | Okay, I see how this can work, now. |
| 02:44 | <@ToxicFrog> | Unless you wanted to make objects in the core memory-managed by lua (and thus subject to garbage collection, etc) which is a pretty major win in some cases, but not, I suspect, here. |
| 02:45 | <@ToxicFrog> | (and even if you did, you could make the interface later export a proxy object with a destructor that deletes the *real* object) |
| 02:45 | <+Consul> | Yeah, the inner DSP loop needs to be pretty clean and fast. |
| 02:45 | <+Consul> | In fact, I've discovered that real-time programming actually uses a lot of what might be called bad practices othewrwise, in the name of speed. |
| 02:46 | <+Consul> | Things like not splitting repetitive code out into functions, etc. |
| 02:47 | <@ToxicFrog> | Um |
| 02:47 | <@ToxicFrog> | That's what the inline keyword is for |
| 02:48 | <+Consul> | See, that's why I really shouldn't be the one coding this. |
| 02:48 | <+Consul> | But between me and one other person, we're all we've got. Nobody else seems to care. |
| 02:48 | <@MyCatVerbs> | ToxicFrog: egrerious macro abuse! |
| 02:48 | <+Consul> | You can bet your ass that they'll be happy to use it when we're done, though. |
| 02:48 | <@MyCatVerbs> | Consul: srsly, inlining FTW. |
| 02:49 | <@ToxicFrog> | Are you already familiar with inline, or shall I give you a quick rundown on it? |
| 02:49 | <+Consul> | Naw, I'll look it up when the time comes. |
| 02:49 | <@ToxicFrog> | It only takes a second to explain anyways. |
| 02:49 | <+Consul> | Go for it, then. :-) |
| 02:49 | <@ToxicFrog> | If a function is declared inline, the compiler will not generate actual function calls; instead, it splices the code in directly. |
| 02:50 | <@ToxicFrog> | For example, inline int add(int a, int b) { return a+b; } |
| 02:50 | <@ToxicFrog> | If you call add(1,2) the compiler will emit the same code as though you had just written "a+b" there. |
| 02:50 | <@ToxicFrog> | This is roughly equivalent to: |
| 02:50 | <@ToxicFrog> | #define add(a,b) (a+b) |
| 02:50 | <@MyCatVerbs> | Except when the function's really short and nonrecursive and the compiler does it anyway, without needing the keyword, because you turned -O2 or -O3 on and it doesn't feel like acting like a damn fool today. |
| 02:51 | <@MyCatVerbs> | Which happens approximately... all the damn time. ^^ |
| 02:51 | <@ToxicFrog> | Except it's handled at the compile stage, rather than the preprocessor stage, and it'll play nice with more IDEs and the like than #defines will. |
| 02:51 | <@ToxicFrog> | As MCV says, the compiler will often inline code anyways if you've told it to optimize for speed. |
| 02:51 | <@ToxicFrog> | However, the inlien keyword gives you a way to ensure that a function will be inlined no matter what optimization settings you use. |
| 02:52 | <@MyCatVerbs> | Oh and nasty #include hacks are even worse than they sound, because of side-effectful expressions. |
| 02:52 | <+Consul> | We're designing the inner DSP core to allow nodes in the graph to be code compiled from FAUST, which is a functional audio DSP language which compiled to optimized C++. |
| 02:52 | <+Consul> | compiles* |
| 02:52 | <@MyCatVerbs> | Hah. i can has inlien funktun?! |
| 02:52 | <@ToxicFrog> | Consul: oh, so it is the FAUST-emitted code that's not following best practices? That's totally reasonable. |
| 02:52 | <@ToxicFrog> | Since that code isn't meant to be touched by humans anyways. |
| 02:53 | <+Consul> | ToxicFrog: Exactly. |
| 02:53 | <@MyCatVerbs> | Consider, for shits and giggles: #define SQUARE(x) ((x)*(x)) -- ask yourself what happens when you write SQUARE(x++); :) |
| 02:53 | <@MyCatVerbs> | Consul: yeah, machine-emitted C is allowed to be made up entirely of labels and goto statements for all anyone cares. |
| 02:53 | <+Consul> | MyCatVerbs: I started working through the logic, and now my head hurts. |
| 02:54 | <@MyCatVerbs> | Bonus points if it is, actually, 'cuz that's often a good sign that someone probably used SSA. ;P |
| 02:54 | <@ToxicFrog> | It's not that hard. |
| 02:54 | <+Consul> | Yeah, FAUST does everything for the sake of efficient code. |
| 02:54 | <@ToxicFrog> | Do the substitution: ((x++)*(x++)) |
| 02:54 | <+Consul> | ah, okay! |
| 02:54 | <+Consul> | I was thinking too much. |
| 02:55 | <@MyCatVerbs> | Consul: almost certainly that is not what the person using the SQUARE wanted, aye? |
| 02:55 | <+Consul> | Indeed. |
| 02:57 | <@McMartin> | Not only that, in C++ it isn't even properly defined if x is a class that overloads operator* nonsymmetrically! |
| 02:57 | <+Consul> | So, getting back to Lua and presets for a second, I just need to make sure I understand... |
| 02:57 | <@McMartin> | But now, dinner. |
| 02:57 | <+Consul> | Because I have to sell this to one other. |
| 02:58 | <+Consul> | Lua stores key=>value data in an internal table... |
| 02:58 | <+Consul> | And it's able to directly export that table to a file? |
| 03:00 | <+Consul> | Or there's otherwise an easy way to do so? |
| 03:00 | <@MyCatVerbs> | Yes, it's trivial to marshall Lua data structures to plaintext formats. |
| 03:01 | <+Consul> | Sweet, thanks! |
| 03:01 | <+Consul> | And just as trivial to load it again, I assume. |
| 03:02 | <@ToxicFrog> | More trivial to load it again. |
| 03:03 | <@ToxicFrog> | Saving it requires you to actually write a function to walk the table and write it to disk; a simple one is perhaps five lines, a more robust one 20+. |
| 03:03 | <@ToxicFrog> | (or you can use a predefined one) |
| 03:03 | <@ToxicFrog> | Loading it is a single function call. |
| 03:03 | <+Consul> | Cool... |
| 03:04 | <@ToxicFrog> | So, yes. It stores key=>value pairs in tables. You can have as many tables as you want, you can easily iterate over them and get/set them from C++, you can easily save and load them, and keys and values can be anything you want, including strings, numbers, pointers to C/++ objects, Lua functions, etc |
| 03:04 | <+Consul> | BRB |
| 03:15 | <@ToxicFrog> | "Yup, I totally tried to have a lava fall running through the center of my meeting hall, dropping into an area for my forges... it was all going perfectly until I noticed dwarves burning to death and the 'basement' slowly filling with lava." |
| 03:21 | <+Consul> | Argh. Google Groups' web interface would have to error out right at this moment... |
| 03:23 | <+Consul> | OKay, it finally posted... |
| 03:37 | | Attilla [~The.Attil@92.2.73.ns-20413] has quit [Quit: <Insert Humorous and/or serious exit message here>] |
| 04:25 | | crem [~moo@93.84.92.ns-3508] has joined #code |
| 04:25 | | Vornicus [~vorn@Admin.Nightstar.Net] has joined #code |
| 04:25 | | mode/#code [+o Vornicus] by ChanServ |
| 05:21 | | crem [~moo@93.84.92.ns-3508] has quit [Connection reset by peer] |
| 05:22 | | crem [~moo@93.84.92.ns-3508] has joined #code |
| 05:27 | | crem [~moo@93.84.92.ns-3508] has quit [Ping Timeout] |
| 05:31 | | AFKSkull [~none@Nightstar-7066.dyn.optonline.net] has left #code [] |
| 05:33 | | crem [~moo@93.84.89.ns-5013] has joined #code |
| 05:41 | | crem [~moo@93.84.89.ns-5013] has quit [Connection reset by peer] |
| 05:41 | | crem [~moo@93.84.89.ns-5013] has joined #code |
| 05:55 | | crem [~moo@93.84.89.ns-5013] has quit [Ping Timeout] |
| 06:00 | | AnnoDomini [AnnoDomini@Nightstar-29598.neoplus.adsl.tpnet.pl] has joined #Code |
| 06:01 | | mode/#code [+o AnnoDomini] by ChanServ |
| 06:03 | | crem [~moo@93.84.93.ns-3789] has joined #code |
| 06:44 | | crem_ [~moo@93.84.90.ns-3424] has joined #code |
| 06:45 | | crem [~moo@93.84.93.ns-3789] has quit [Ping Timeout] |
| 06:59 | | Derakon is now known as Derakon[AFK] |
| 07:01 | | crem_ [~moo@93.84.90.ns-3424] has quit [Ping Timeout] |
| 07:04 | | crem [~moo@Nightstar-28703.adsl.mgts.by] has joined #code |
| 07:06 | | gnolam [lenin@Nightstar-2037.A163.cust.bahnhof.se] has joined #Code |
| 07:06 | | mode/#code [+o gnolam] by ChanServ |
| 07:33 | | You're now known as TheWatcher |
| 07:56 | | gnolam [lenin@Nightstar-2037.A163.cust.bahnhof.se] has quit [Ping Timeout] |
| 08:09 | | You're now known as TheWatcher[afk] |
| 08:13 | | gnolam [lenin@Nightstar-2037.A163.cust.bahnhof.se] has joined #Code |
| 08:13 | | mode/#code [+o gnolam] by ChanServ |
| 08:36 | | crem [~moo@Nightstar-28703.adsl.mgts.by] has quit [Connection reset by peer] |
| 08:36 | | crem [~moo@Nightstar-28703.adsl.mgts.by] has joined #code |
| 10:27 | | Reiver [~reaverta@Admin.Nightstar.Net] has quit [Ping Timeout] |
| 10:33 | | Reiver [~reaverta@Admin.Nightstar.Net] has joined #Code |
| 10:33 | | mode/#code [+o Reiver] by ChanServ |
| 10:48 | | You're now known as TheWatcher |
| 11:17 | | Attilla [~The.Attil@92.2.73.ns-20413] has joined #code |
| 11:17 | | mode/#code [+o Attilla] by ChanServ |
| 11:23 | | Attilla [~The.Attil@92.2.73.ns-20413] has quit [Ping Timeout] |
| 11:32 | | Brother_Willibald [lenin@Nightstar-2037.A163.cust.bahnhof.se] has joined #Code |
| 11:32 | | gnolam is now known as NSGuest-470 |
| 11:32 | | Brother_Willibald is now known as gnolam |
| 11:33 | | NSGuest-470 [lenin@Nightstar-2037.A163.cust.bahnhof.se] has quit [Ping Timeout] |
| 11:39 | | Attilla [~The.Attil@92.2.73.ns-20413] has joined #code |
| 11:39 | | mode/#code [+o Attilla] by ChanServ |
| 11:41 | | Kazriko [~kaz@Nightstar-26352.gdj-co.client.bresnan.net] has quit [Client exited] |
| 11:46 | | Kazriko [~kaz@Nightstar-26352.gdj-co.client.bresnan.net] has joined #code |
| 11:46 | | mode/#code [+o Kazriko] by ChanServ |
| 12:14 | | Attilla [~The.Attil@92.2.73.ns-20413] has quit [Ping Timeout] |
| 12:15 | | Attilla [~The.Attil@92.2.73.ns-20413] has joined #code |
| 12:15 | | mode/#code [+o Attilla] by ChanServ |
| 13:37 | | Thaqui [~Thaqui@Nightstar-13764.jetstream.xtra.co.nz] has left #code [MORE constitution LESS destitution MORE pros...perity.] |
| 14:58 | | You're now known as TheWatcher[afk] |
| 16:53 | | gnolam [lenin@Nightstar-2037.A163.cust.bahnhof.se] has quit [Ping Timeout] |
| 16:54 | | Shoukanjuu [~Shoukanju@Nightstar-27098.101.8.67.cfl.res.rr.com] has quit [Ping Timeout] |
| 17:02 | | gnolam [lenin@Nightstar-2037.A163.cust.bahnhof.se] has joined #Code |
| 17:02 | | mode/#code [+o gnolam] by ChanServ |
| 17:07 | | Reiver [~reaverta@Admin.Nightstar.Net] has quit [Ping Timeout] |
| 17:11 | | gnolam [lenin@Nightstar-2037.A163.cust.bahnhof.se] has quit [Ping Timeout] |
| 17:14 | | Reiver [~reaverta@Admin.Nightstar.Net] has joined #Code |
| 17:14 | | mode/#code [+o Reiver] by ChanServ |
| 17:46 | | * ToxicFrog kicks C++ in the balls over and over again |
| 17:52 | <@ToxicFrog> | It should not be this difficult to dynamically generate the number of arguments to a function at runtime! |
| 17:59 | <@Vornicus> | ah, good times. |
| 18:03 | | AnnoDomini is now known as Greenbeard |
| 18:04 | <@ToxicFrog> | And by "difficult" I mean "impossible", since the function takes ... rather than va_list |
| 18:04 | <@ToxicFrog> | Barring stupid pointer tricks that I'm very reluctant to use. |
| 18:04 | <@Vornicus> | :( |
| 18:05 | <@ToxicFrog> | Really, this whole stats framework kind of falls apart when you need to dynamically generate both the number of stats and their names, and C++ is not being helpful. |
| 18:11 | <@Vornicus> | Kill. |
| 18:14 | <+Consul> | Normally, since C++ is the compiled language of my choice, I would jump to its defense. However, I only hate it a little less than others, so I don't feel compelled defend it at all, really. |
| 18:16 | <+Consul> | In fact, I often want to stab it with a brick. |
| 18:36 | <@ToxicFrog> | In this case, I have a data structure that defines the display formats of a bunch of stats, a function call that generates a format string from that, and a CK_Snprintf() call that expects to be passed the format string and the actual numbers that make up the stats. |
| 18:37 | <@ToxicFrog> | Unfortunately, the names of the stats are generated at runtime, and while the number of stats is technically determinable at compile time it would be really nice to be able to do it at runtime. |
| 18:45 | | You're now known as TheWatcher |
| 19:34 | <+Consul> | Heck with it. I'm just gonna go ahead, research and build the Lua stuff I want for my synth and sampler. I'm tired of having conversations with myself on our public mailing list. |
| 19:36 | <@ToxicFrog> | Froth |
| 19:36 | <@ToxicFrog> | Is there any way to do iteration in cpp? |
| 19:36 | | jerith [~jerith@IRCop.Nightstar.Net] has quit [Ping Timeout] |
| 19:37 | | jerith [~jerith@Nightstar-21563.slipgate.za.net] has joined #code |
| 19:37 | <@ToxicFrog> | Consul: as far as the lua stuff goes, useful resources - |
| 19:37 | <@ToxicFrog> | www.lua.org/manual/5.1/ -- the reference manual |
| 19:37 | <+Consul> | I'm already reading that one. :-) |
| 19:38 | <@ToxicFrog> | www.lua.org/pil/ -- an introductory text (now somewhat out of date, but still useful in places) |
| 19:38 | <@ToxicFrog> | www.lua-users.org/wiki/ -- the wiki, full of tasty stuff |
| 19:38 | <+Consul> | And I do want to say that my partner in crime has done a bang-up job on the JACK and voice abstract classes. |
| 19:38 | <@ToxicFrog> | http://www.lua.org/lua-l.html -- the mailing list |
| 19:39 | <@ToxicFrog> | #lua on irc.freenode.org -- the official IRC channel |
| 19:39 | <+Consul> | There's an ITC channel in Freenode, too. |
| 19:39 | <+Consul> | IRC I mean |
| 19:39 | <@ToxicFrog> | Yes, I'm in it :P |
| 19:41 | <+Consul> | But putting Lua in between incoming MIDI/OSC and the engine opens up a lot of ideas. |
| 19:42 | <+Consul> | Suddenly, things like velocity layers, velocity crossfading, and positional crossfading can be scripted. |
| 19:45 | <+Consul> | Now I just need to figure out a clean way of creating that functionality. |
| 19:46 | | Attilla [~The.Attil@92.2.73.ns-20413] has quit [Ping Timeout] |
| 19:47 | | Attilla [~The.Attil@92.17.251.ns-11974] has joined #code |
| 19:47 | | mode/#code [+o Attilla] by ChanServ |
| 20:02 | <@ToxicFrog> | Consul: I again suggest starting with the KV load/save functionality |
| 20:02 | <@ToxicFrog> | It's simple to design, it's simple to implement, it'll give you some familiarity with the language and how it interfaces with C++, and it can easily be built on. |
| 20:35 | <+Consul> | ToxicFrog: Sounds like a good plan to me. |
| 20:47 | | Greenbeard [AnnoDomini@Nightstar-29598.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 20:54 | | AnnoDomini [AnnoDomini@Nightstar-29533.neoplus.adsl.tpnet.pl] has joined #Code |
| 20:54 | | mode/#code [+o AnnoDomini] by ChanServ |
| 21:54 | | You're now known as TheWatcher[t-2] |
| 21:56 | | You're now known as TheWatcher[zZzZ] |
| 22:51 | | androsch [~androsch@Nightstar-2639.pools.arcor-ip.net] has joined #code |
| 23:02 | | AnnoDomini [AnnoDomini@Nightstar-29533.neoplus.adsl.tpnet.pl] has quit [Quit: No fighting in the War Room!] |
| 23:07 | | jerith [~jerith@Nightstar-21563.slipgate.za.net] has quit [Ping Timeout] |
| 23:07 | | jerith [~jerith@Nightstar-21563.slipgate.za.net] has joined #code |
| --- Log closed Sat Aug 09 00:00:30 2008 |