| --- Log opened Tue Jan 13 00:00:02 2009 |
| 00:04 | <@McMartin> | Those usually show up as subsets of engineering or physics. |
| 00:04 | <@McMartin> | Bioinformatics is usually part of the Bio department, not CS |
| 00:12 | <@Consul> | Anyway, I was looking up some stuff on how to make a new language, and I didn't get very far. I know it involves a parser and a lexer, all of which I would think are pretty well documented. |
| 00:13 | <@ToxicFrog> | Well, not necessarily |
| 00:13 | <@ToxicFrog> | But in general, yes; the lexer splits the input into tokens (this is a string, this is a number, this is a name, this is a '{') |
| 00:13 | <@ToxicFrog> | And the parser takes the token stream and derives meaning from it. |
| 00:14 | <@Consul> | So is there a reason why I couldn't (and maybe shouldn't) write a compiler in, say, Python? |
| 00:14 | <@ToxicFrog> | There are techniques (such as PEGs) that let you do the whole thing in one step, and some languages (postscript comes to mind) don't really have a parser, just a lexer. |
| 00:14 | <@ToxicFrog> | Python would be admirably suited to compiler writing, I should think. |
| 00:14 | <@ToxicFrog> | ISTR McM wrote an assembler in it |
| 00:18 | | * ToxicFrog hugs his copy of the Dragon Book |
| 00:18 | <@Consul> | The Dragon Book? |
| 00:18 | <@ToxicFrog> | Compilers: Principles, Techniques, and Tools, Aho & Ullman. |
| 00:18 | <@Consul> | The Flagon with the Dragon Book? :-) |
| 00:18 | <@ToxicFrog> | The text on compiler design, although it's a bit heavy. |
| 00:19 | <@ToxicFrog> | The name comes from the cover artwork, which is of a dragon named Complexity of Compiler Design fighting a knight armed with LALR Parser Generators and armoured with Syntax-Directed Translation. |
| 00:19 | <@Consul> | Well, my aim would be to make something specific to audio effects/DSP algos. |
| 00:20 | <@ToxicFrog> | A language specific to that? |
| 00:20 | <@Consul> | yeah |
| 00:20 | <@Consul> | But with editor, compiler, and GUI wrapped up in a plugin. |
| 00:20 | <@ToxicFrog> | In that case, first of all, the big question: what will make it preferable to other, existing languages? |
| 00:20 | <@Consul> | Well, ideally, one could be a math guy not versed in any language and still use this one. |
| 00:21 | <@ToxicFrog> | The question stands; there will always be some learning curve no matter the language, and there's plenty of languages written to be easy to use. |
| 00:22 | <@ToxicFrog> | Note that I'm not trying to discourage you; but this is a question you should have an answer for before you start implementing :) |
| 00:22 | <@Consul> | Self fulfillment, then? |
| 00:22 | <@ToxicFrog> | (and "it won't, but I'll have fun making it" is a valid answer) |
| 00:22 | | You're now known as TheWatcher[T-2] |
| 00:23 | <@Consul> | Well, Jesusonic is basically a built-in language for making one's own plugins within Reaper. |
| 00:23 | <@Consul> | But it has some oddball syntax sometimes. |
| 00:24 | <@Consul> | And of course, it's biggest failing, it exists only within Reaper. |
| 00:24 | <@ToxicFrog> | Well, pitch your language idea :) |
| 00:25 | <@Consul> | Oh, I have no idea what I'm doing. :-) |
| 00:25 | | You're now known as TheWatcher[zZzZ] |
| 00:25 | | * ToxicFrog ponders Mapper |
| 00:25 | <@ToxicFrog> | ...I'm an idiot. |
| 00:25 | <@ToxicFrog> | I've been doing all this work on serialization and data formats and whatnot - ok, not much work, since I wrote a serializer a few months ago and can drop that in, but still some to figure out how things should be structured and whatnot - |
| 00:25 | <@Consul> | But let me give you an idea of what I see in my head for the *plugin*, before we talk about the language itself. |
| 00:25 | <@ToxicFrog> | - when I could just be doing: |
| 00:26 | <@ToxicFrog> | require "ldb" |
| 00:26 | <@ToxicFrog> | local database = ldb.new() |
| 00:26 | <@ToxicFrog> | And using that. |
| 00:26 | <@ToxicFrog> | Consul: sure. Plugin for what, though? |
| 00:26 | <@Consul> | Real-time audio processing. |
| 00:27 | <@ToxicFrog> | No, I mean, what does it plug into? |
| 00:27 | <@Consul> | A multitrack audio host, like Ardour. |
| 00:27 | <@ToxicFrog> | So...would you be writing this host? Or do you have an existing app in mind? Or will this be a general plugin arch that can target any of them? |
| 00:28 | <@Consul> | It would be a common plugin arch. |
| 00:28 | <@Consul> | Like LV2. |
| 00:28 | <@Consul> | Which is supported by several host apps. |
| 00:28 | <@ToxicFrog> | Ok. |
| 00:28 | <@Consul> | Or a JACK client. |
| 00:28 | <@ToxicFrog> | So, this plugin. |
| 00:29 | <@ToxicFrog> | It would accept filters(?) written in this language and apply them? |
| 00:30 | <@Consul> | Well, in short. |
| 00:30 | <@Consul> | But there would be an editor and a GUI for the filter being made. |
| 00:30 | <@Consul> | The editor would have a button for compiling the filter. |
| 00:30 | <@Consul> | Then on another tab, the GUI for that filter would be generated. |
| 00:30 | <@Consul> | That's the basic dream, anyway. |
| 00:32 | <@Consul> | Of course, the GUI would really just be sliders or text boxes or whatever basic widget would be appropriate. |
| 00:33 | <@Consul> | The idea, then, would be to make sliders/inputs easy to define, and then make part of the algorithm, within the language, so the coder only need think about the algorithm. |
| 00:33 | <@Consul> | Inputs and outputs to the host could also be automatically taken care of. |
| 00:34 | <@Consul> | BRB |
| 00:35 | <@ToxicFrog> | And the filter would be compiled into...VM bytecode? Native machine language? A conveniently loadable IR? |
| 00:38 | <@McMartin> | Other possible target: C or C++ source code to be compiled later into native machine code |
| 00:41 | <@ToxicFrog> | Truth. |
| 00:42 | <@Consul> | Anyway, Jesusonic had many obvious problems, the biggest of which was the lack of functions, and it's channel handling was crap. So if you wanted to create a stereo effect, you copied and pasted code, then changed all of the variable names for the new channel, including pre-defined var names. |
| 00:43 | <@Vornicus> | ..."Jesusonic" |
| 00:43 | <@Consul> | Vornicus: A part of Reaper, basically a small compiled programming language to make DSP effects for audio. |
| 00:43 | <@Consul> | Reaper is a digital audio workstation on Windows. |
| 00:43 | <@Consul> | A very, very good one, actually. |
| 00:45 | <@Consul> | Anyway, in addition to functions and channel handling, I was thinking some improvements could be made in referring to past inputs and outputs to the algorithm, instead of manually shifting values around using variables, like a homemade stack. |
| 00:46 | <@ToxicFrog> | Well, if you have some mechanism for referring to "this input at N iterations ago", a sufficiently smart compiler can, based on that, figure out how much of each input it needs to remember at runtime |
| 00:48 | <@Consul> | Faust uses prime notation, basically. If you have a variable referring to the input (typically x), referring to x' automatically retrieves last iteration's value of x. |
| 00:48 | <@Consul> | x'' does exactly what you think it might. :-) |
| 00:48 | <@Consul> | You can do the same with the output y. |
| 00:49 | <@Consul> | (You don't need to use x and y, but in Faust, those are basically "automatic".) |
| 00:55 | | Derakon[AFK] is now known as Derakon |
| 00:57 | <@ToxicFrog> | I was thinking something like that, yes. |
| 00:58 | <@ToxicFrog> | with x'n as a synonym for x followed by n ' |
| 00:59 | <@McMartin> | 16:47 <@ToxicFrog> Well, if you have some mechanism for referring to "this input at N iterations ago", a sufficiently smart compiler can, based on that, figure out how much of each input it needs to remember at runtime |
| 00:59 | <@McMartin> | Only if N is constant |
| 00:59 | <@McMartin> | Otherwise you hit the halting problem. Or rather, it hits you, right in the decidability |
| 00:59 | <@Derakon> | Ouch! My decidability! |
| 01:00 | <@Derakon> | I needed that for proving P=NP! |
| 01:02 | <@ToxicFrog> | McMartin: true. I assumed that n is constant. |
| 01:02 | <@Consul> | Well, in DSP, it can be known at compile time how many previous inputs and outputs will be needed. |
| 01:16 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: Z?] |
| 01:17 | <@Consul> | Programs would need to split into three sections: Init, which is code that only runs on startup. Interface, which is code that runs at the sample rate (once per tick) but only when a UI element is touched. Audio, which runs at sample rate all the time. |
| 01:18 | <@Consul> | The Interface block is also what would define how the UI elements get drawn. |
| 01:19 | <@ToxicFrog> | It seems like Interface should be controlling the parameters of Audio. |
| 01:19 | <@Consul> | Yes |
| 01:19 | <@Consul> | So that block would have to run before Audio |
| 01:19 | <@ToxicFrog> | Well, what I mean is |
| 01:19 | <@ToxicFrog> | Why does interface have to "run at the sample rate"? |
| 01:19 | <@Derakon> | Heh. |
| 01:20 | <@Derakon> | I've just found an effective way to combat the doomcircle pattern. |
| 01:20 | <@Derakon> | Namely, park on the emitter before it starts, get hit by the very first bullet...and none of the rest will spawn. |
| 01:20 | <@ToxicFrog> | It seems like it would be more like: touching the UI changes some parameters to audio (which are declared as visible in the interface somewhere, along with what sort of widgets and so forth), and those changes are reflected the next time audio ticks. |
| 01:20 | <@Derakon> | Ultimately you can't do better than hold steady with this, though, since you get one bonus bomb per pass through all of the patterns, and it resets your score multiplier. |
| 01:22 | <@Consul> | ToxicFrog: Because the audio has to react to how the controls get touched in real time. |
| 01:22 | <@Consul> | If I grab a slider and move it, I want to hear the audio change. |
| 01:22 | <@Consul> | Thus, as a UI element value changes, that has to affect the audio, at the sample rate. |
| 01:23 | <@Consul> | But any calculations done in the Interface block don't have to run when no UI element is being touched. |
| 01:23 | <@ToxicFrog> | Right. |
| 01:23 | <@Derakon> | What, are you writing a mixer or something? |
| 01:23 | <@ToxicFrog> | But my point is, the interface block doesn't need to run every tick. |
| 01:24 | <@ToxicFrog> | ...oh wait, I think I see what you mean |
| 01:24 | <@ToxicFrog> | User adjusts UI -> UI is marked dirty -> on next tick, changes to UI are collected and applied ? |
| 01:24 | <@Consul> | ToxicFrog: It does if a calculation being done in their is depended upon by the main algorithm, and that happens a lot. Calculating filter poles, for example. |
| 01:24 | <@Consul> | ToxicFrog: Exactly. |
| 01:24 | <@ToxicFrog> | (as opposed to just collecting changes every time a change to the UI is made) |
| 01:24 | <@Consul> | And in there is what I meant. Blargh. |
| 01:25 | <@ToxicFrog> | Ok. That makes sense. |
| 01:29 | <@Consul> | Now, since I want to make the UI a part of the total experience, I could actually give the editor three different editing areas. |
| 01:37 | <@Consul> | Anyway, I suppose once a DSP program is written in this thing, hitting compile would compile the code then launch it in its own process hooked up to the host. |
| 01:39 | <@Consul> | Which actually just launched an entire slew of complications in my head, based upon how plug-ins interface with the host. :-/ |
| 01:41 | <@McMartin> | You probably do not want to be firing off a compiler every time someone tweaks a knob |
| 01:42 | <@Consul> | Oh no, only when they hit the compile button on the editor itself. |
| 01:42 | <@Consul> | The knob tweaking is only for when the DSP process is active. |
| 01:55 | <@ToxicFrog> | McMartin: AIUI, the compiler emits (basically) three units of code: one that runs at load time, one that runs on next tick when inputs are adjusted, and one that runs every tick. |
| 01:56 | <@Consul> | In that exact order, as it should turn out. :-) |
| 02:14 | <@McMartin> | Heh. |
| 02:14 | <@McMartin> | Me: AUGH EVERYBODY IN THE ENTIRE WORLD IS DOING IT WRONG |
| 02:14 | <@McMartin> | My boss: Excellent! You are now a real software engineer! |
| 02:16 | | * Alek yays |
| 03:24 | | * Derakon updates his bullet graphics. http://derakon.dyndns.org/~chriswei/temp/bulletmlscreen7.png |
| 03:25 | <@Derakon> | Actually, I'm gonna go give each bullet its own frame counter. Just a moment... |
| 03:27 | <@Derakon> | Yeah, that's much better. http://derakon.dyndns.org/~chriswei/temp/bulletmlscreen7b.png |
| 03:28 | <@Vornicus> | ...mcshiny. |
| 03:28 | <@Derakon> | At this point, the ugliest things on that screen are the font, and the player ship. |
| 03:28 | <@Derakon> | The former being Pygame's built-in, and the latter being made in maybe fifteen minutes. |
| 03:29 | | * Vornicus agrees. |
| 03:29 | <@Derakon> | (Mind you, given that all that you can see in that screenshot are bullets, the ship, and the font...) |
| 03:30 | <@Derakon> | Idly, it's amazing how handy 3D modeling programs are for making sprites. |
| 03:45 | | * Derakon revels in the cleansing power of holy shit this pattern gets hard. |
| 03:54 | < ASCII> | what's that, Der, the sunflower of death? |
| 04:06 | <@Derakon> | The screenshot is of the "bigspiral" pattern. Pretty simple, but it scales nicely. |
| 04:06 | <@Derakon> | My comment of 19:44 was on a new one I'm working on: http://derakon.dyndns.org/~chriswei/temp/bulletmlscreen7c.png |
| 04:07 | <@Derakon> | In short, the emitter fires red bullets to either side; those bullets wait a bit, then fire a few blue bullets at random, and a yellow bullet at the player. |
| 04:49 | <@Derakon> | http://derakon.dyndns.org/~chriswei/temp/bulletml6.tgz |
| 04:49 | <@Derakon> | Run the gauntlet of eight deadly bullet patterns! Then run it again! And again! |
| 04:56 | <@Vornicus> | ah ah ah ah ah? |
| 04:58 | <@Derakon> | Er, yes. Pretend I laughed at the right time. |
| 04:59 | <@Derakon> | FWIW, they're named bigspiral, homelaser, spiral, crossfire, counterspiral, homebullet, doomcircle, and scatterscatter, in that order. |
| 05:22 | | * Derakon figures out how to save surfaces to disk, makes an animation: http://derakon.dyndns.org/~chriswei/temp/bulletmlanim1.gif |
| 05:28 | <@Vornicus> | jeeeezus |
| 05:29 | <@Derakon> | To be fair, that's at rank 5. I generally figure the game should be decently challenging at rank 3 and downright hard at 5. Currently it's 8 seconds per pattern and 8 patterns per rank, so that's several minutes into the game. |
| 05:30 | <@Derakon> | (Sadly, 5FPS is not sufficient tool-assistance for me to play around) |
| 06:00 | | Reiv [ReivTop@Nightstar-24773.ipnet.xnet.co.nz] has joined #Code |
| 06:40 | | Derakon is now known as Derakon[AFK] |
| 06:46 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has quit [Operation timed out] |
| 06:50 | | ToxicFrog [~ToxicFrog@67.212.7.ns-3924] has joined #code |
| 06:50 | | mode/#code [+o ToxicFrog] by ChanServ |
| 06:55 | | AnnoDomini [~farkoff@Nightstar-29692.neoplus.adsl.tpnet.pl] has joined #Code |
| 06:55 | | mode/#code [+o AnnoDomini] by ChanServ |
| 07:59 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has joined #Code |
| 07:59 | | mode/#code [+o gnolam] by ChanServ |
| 08:41 | | KBot [AnnoDomini@Nightstar-29721.neoplus.adsl.tpnet.pl] has joined #Code |
| 08:41 | | AnnoDomini [~farkoff@Nightstar-29692.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 08:42 | | KarmaBot [AnnoDomini@Nightstar-29692.neoplus.adsl.tpnet.pl] has quit [Ping Timeout] |
| 08:44 | | KBot is now known as KarmaBot |
| 08:49 | | AnnoDomini [~farkoff@Nightstar-29721.neoplus.adsl.tpnet.pl] has joined #Code |
| 08:49 | | mode/#code [+o AnnoDomini] by ChanServ |
| 09:17 | | You're now known as TheWatcher |
| 10:01 | <@Vornicus> | I find myself building a "phone book" metaphor for SQL's "VACUUM" command. |
| 10:02 | <@Vornicus> | (it involves white out and post-its.) |
| 10:49 | | Reiv [ReivTop@Nightstar-24773.ipnet.xnet.co.nz] has quit [Quit: Laptop fall down go boom...] |
| 11:06 | | Vornicus [~vorn@Admin.Nightstar.Net] has quit [Quit: ] |
| 11:55 | | gnolam [lenin@Nightstar-1382.A163.priv.bahnhof.se] has quit [Quit: Estocolmo] |
| 12:37 | | gnolaptop [~lenin@91.149.38.ns-26870] has joined #Code |
| --- Log closed Tue Jan 13 12:47:28 2009 |
| --- Log opened Tue Jan 13 12:53:33 2009 |
| 12:53 | | TheWatcher [~chris@Nightstar-29731.dsl.in-addr.zen.co.uk] has joined #code |
| 12:53 | | Irssi: #code: Total of 24 nicks [14 ops, 0 halfops, 1 voices, 9 normal] |
| 12:53 | | mode/#code [+o TheWatcher] by ChanServ |
| 12:54 | | Irssi: Join to #code was synced in 51 secs |
| 14:17 | | gnolam [~lenin@91.149.38.ns-26870] has quit [Ping Timeout] |
| 14:35 | | gnolam [~lenin@Nightstar-19043.dialup.nmt.net] has joined #Code |
| 14:36 | | gnolam is now known as NSGuest-1052 |
| 14:42 | | NSGuest-1052 is now known as gnolam |
| 14:44 | | gnolam [~lenin@Nightstar-19043.dialup.nmt.net] has quit [Quit: Hey look, I'm there.] |
| 15:08 | | ToxicFrog [~ToxicFrog@67.212.7.ns-3924] has quit [Quit: Back in a moment] |
| 15:09 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has joined #code |
| 15:09 | | mode/#code [+o ToxicFrog] by ChanServ |
| 18:15 | | * ToxicFrog strangles javascript |
| 18:17 | <@Consul> | Can I help? |
| 18:17 | <@Consul> | I'll hold it down. |
| 18:32 | <@ToxicFrog> | return new Number(images[i].parentNode.parentNode.cells[images[i].parentNode.cellIndex+1].i nnerHTML); |
| 18:32 | <@ToxicFrog> | ;.; |
| 18:45 | | Attilla [~The.Attil@Nightstar-9469.cdif.cable.ntl.com] has quit [Ping Timeout] |
| 18:48 | | Attilla [~The.Attil@Nightstar-9469.cdif.cable.ntl.com] has joined #code |
| 18:48 | | mode/#code [+o Attilla] by ChanServ |
| 19:06 | <@ToxicFrog> | Oh hey, that can actually be done much more simply. |
| 19:06 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has left #code [Leaving] |
| 19:06 | | ToxicFrog [~ToxicFrog@Admin.Nightstar.Net] has joined #code |
| 19:06 | | mode/#code [+o ToxicFrog] by ChanServ |
| 19:07 | <@ToxicFrog> | return new Number(images[i].parentNode.nextSibling.innerHTML) |
| 20:03 | | * ToxicFrog strangles Firefox |
| 20:03 | <@ToxicFrog> | It's domulating this thing oddly. |
| 20:04 | <@ToxicFrog> | Inserting empty TEXT elements between everything. |
| 20:12 | | Vornicus [~vorn@Admin.Nightstar.Net] has joined #code |
| 20:12 | | mode/#code [+o Vornicus] by ChanServ |
| 20:13 | <@MyCatVerbs> | Hrmn, does anyone know if there's a convenient way (something like Citeseer, perhaps) to see if there are any patents that have referenced a particular paper, please? |
| 20:17 | | You're now known as TheWatcher[afk] |
| 21:07 | <@McMartin> | MCV: I *believe* the USPTO has searchable archives, but I'm not sure how one goes about doing this. |
| 21:42 | | You're now known as TheWatcher |
| 22:30 | | C_tiger [~cheng@Nightstar-5625.hsd1.ca.comcast.net] has quit [Ping Timeout] |
| 22:33 | | C_tiger_remote [~cheng@Nightstar-5625.hsd1.ca.comcast.net] has joined #code |
| 22:33 | | mode/#code [+o C_tiger_remote] by ChanServ |
| 22:45 | | C_tiger [~c_wyz@Nightstar-5625.hsd1.ca.comcast.net] has joined #code |
| 22:45 | | mode/#code [+o C_tiger] by ChanServ |
| 22:45 | | C_tiger [~c_wyz@Nightstar-5625.hsd1.ca.comcast.net] has quit [Quit: And away she goes!] |
| 22:45 | | C_tiger_remote is now known as C_tiger |
| 23:52 | | C_tiger [~cheng@Nightstar-5625.hsd1.ca.comcast.net] has quit [Ping Timeout] |
| 23:53 | | C_tiger_remote [~cheng@Nightstar-5625.hsd1.ca.comcast.net] has joined #code |
| 23:53 | | mode/#code [+o C_tiger_remote] by ChanServ |
| 23:55 | | Attilla [~The.Attil@Nightstar-9469.cdif.cable.ntl.com] has quit [Quit: <Insert Humorous and/or serious exit message here>] |
| --- Log closed Wed Jan 14 00:00:07 2009 |