code logs -> 2008 -> Sat, 02 Aug 2008< code.20080801.log - code.20080803.log >
--- Log opened Sat Aug 02 00:00:21 2008
00:29 MyCatVerbs [~mycatverb@Nightstar-13709.lurkingfox.co.uk] has quit [Connection reset by peer]
00:31 MyCatVerbs [~mycatverb@Nightstar-13709.lurkingfox.co.uk] has joined #code
00:31 mode/#code [+o MyCatVerbs] by ChanServ
00:40 Vornicus [~vorn@Admin.Nightstar.Net] has quit [Ping Timeout]
00:44 Vornotron [~vorn@Admin.Nightstar.Net] has joined #code
02:15 Vornotron is now known as Vornicus
02:35 Shoukanjuu [~Shoukanju@Nightstar-27098.101.8.67.cfl.res.rr.com] has joined #code
02:37 Thaqui [~Thaqui@Nightstar-13764.jetstream.xtra.co.nz] has joined #code
02:37 mode/#code [+o Thaqui] by ChanServ
03:08 Attilla [~The.Attil@92.20.0.ns-26568] has quit [Quit: <Insert Humorous and/or serious exit message here>]
03:27
<@McMartin>
What, if any is needed, is the apt equivalent for "yum clean all"?
03:33 Kazriko [~kaz@Nightstar-26352.gdj-co.client.bresnan.net] has quit [Operation timed out]
03:43 Kazriko [~kaz@Nightstar-26352.gdj-co.client.bresnan.net] has joined #code
03:43 mode/#code [+o Kazriko] by ChanServ
03:48
<@Kazriko>
what does yum clean all do?
04:07
<@McMartin>
Removes all cached information regarding repository state, and also, if you've been keeping downloaded packages around, wipes those out too.
04:08
<@Kazriko>
you know, I've never needed that function. I think update does the first, or at least it reloads it all from the servers
04:09
<@Kazriko>
the cache clearing is available seperately i know, might be built in on newer apts, i'll have to look
04:10
<@McMartin>
Yeah. yum can be configured to do it (or you just bung in a cron job that calls it monthly, etc.) but I know the command for it
04:11
<@McMartin>
Usually the only important bit is the cache; cleaning the metadata is only necessary if you've corrupted it somehow
04:11
<@McMartin>
However, I'm critically low on space on my Ubuntu machine and I don't know how to do do the equivalent (cache cleaning) - or if I need to.
04:11
<@Kazriko>
i know the cache clearing happens on reboot, i think there might be a cron job.
04:12
<@McMartin>
'k.
04:12
<@Kazriko>
with synaptic there's a setting to delete the cache after install
04:13
<@Kazriko>
apt auto-clean does more i think
04:13
<@McMartin>
Cool, thanks
04:13
<@Kazriko>
it looks like its not in a cron job on my system
04:14
<@Kazriko>
ok, apt-get clean
04:14
<@Kazriko>
clears the cache only
04:14
<@McMartin>
That looks like what I want.
04:14
<@McMartin>
The autoclean is if you use it as a dselect tool, which I don't believe I do.
04:15
<@McMartin>
... yeah. From 99% usage to 68% usage according to df.
04:15
<@McMartin>
Well then.
04:15
<@McMartin>
Much appreciated. =)
04:16
<@Kazriko>
let me know if theres any other problems, i'll look it up
04:33
<@McMartin>
I think that did what it needed to
04:52
< Consul>
Okay, so throwing an exception within an object calls that object's destructor... That's fine for more serious errors, like being out of memory or violating kernel space or something like that.
04:53
< Consul>
But what if I want to throw an error, leave the functions, but leave the object intact/
04:53
< Consul>
?
04:53
< Consul>
leave the function, I mean
04:54
<@McMartin>
Then you'd damn well better not declare it on the stack.
04:54
< Consul>
I'm just trying to handle errors like "file not found" or not having permissions to write to a directory and stuff like that.
04:54
<@McMartin>
If it's a heap object, it will not be destruxx0r3d.
04:54
< Consul>
But my object needs to stay intact.
04:54
<@McMartin>
Um
04:54
<@McMartin>
Do I have you right that the caller looks like this:
04:55
<@McMartin>
void foo() { file_obj A(); A.open("blah"); ... stuff }
04:55
<@ToxicFrog>
He's writing a library, I believe
04:55
<@McMartin>
And open can throw an exception, which will be caught by foo's caller, and you want A to stay intact?
04:55
< Consul>
Well, I'm creating an fstream object, but yeah, basically.
04:55
<@McMartin>
OK, see, that fstream object won't survive a return, much less a throw.
04:56
< Consul>
But if I throw from within the object I'm calling the fstream object from, which is my PresetManager object...
04:56
<@ToxicFrog>
Consul: thing is, A there is declared on stack
04:57
<@ToxicFrog>
A.open throws, the throw causes foo() to be left entirely
04:57
<@McMartin>
As soon as foo's stack frame goes away, for any reason, A goes bye-bye.
04:57
<@ToxicFrog>
Thus losing its stack frame
04:57
<@McMartin>
Put it on the heap by making it with new, take it as an argument, whatever, but You Can't Do This.
04:58
< Consul>
I don't care if the fstream object goes away. I destroy that anyway after I parse the file into a list and a map.
04:58
< Consul>
I don't want to throw to outside my PresetManager (so the calling program can make a shiny error window) and lose the PresetManager object.
04:58
<@McMartin>
So... have the caller to foo catch the exceptions?
04:59
<@ToxicFrog>
Er
04:59
<@McMartin>
AFAIK the object isn't destroyed until the stack frame goes away; stack frames go away due to returns or due to an exception not being caught within that frame.
04:59
<@ToxicFrog>
Isn't it, based on what you said earlier, the job of the calling program to catch the exception?
04:59
<@ToxicFrog>
They need to be made aware something went wrong, so that, as you say, they can make an error window or print to stderr or however they handle errors
04:59
< Consul>
Well, what I've read says I can throw an exception I catch further outside the frame I'm in.
05:00
<@McMartin>
Well, yes, that is rather the point of exceptions.
05:00
<@ToxicFrog>
Yes, that's kind of the point
05:00
<@McMartin>
So, you know, anything that falls out of scope because of this, and that is a stack variable, gets destroyed.
05:00
< Consul>
So, if the fstream object throws an error, I can catch it within PresetManager, and throw it out again.
05:00
< Consul>
But I don't really need to do that, do I
05:00
<@McMartin>
Any heap objects that go out of scope because of this leak.
05:00
< Consul>
?
05:00
<@ToxicFrog>
...why do you need to catch it and re-throw?
05:00
<@McMartin>
That depends. Is PresetManager doing something before the rethrow?
05:00
< Consul>
Since the stack will unwind automatically.
05:00
<@ToxicFrog>
If the PresetManager doesn't catch it at all, it'll propagate upwards
05:01
< Consul>
McMartin: No, I just want to handle errors properly.
05:01
<@ToxicFrog>
Until it's caught or it leaves main() (and kills the program thereby)
05:01
<@ToxicFrog>
So unless the PresetManager needs to do something in response to the exception, the correct response is not to catch it
05:01
< Consul>
ToxicFrog: So, if it propogates out of PresetManager, it won't call PresetManager's destructor, will it?
05:02
<@McMartin>
Only if it has somehow declared itself as a stack variable within its own frame.
05:02
<@McMartin>
Which is only possibly for static functions.
05:02
<@ToxicFrog>
...that depends on whether the PresetManager is unscoped as a result of this
05:02
< Consul>
The only issue now is I need to halt execution of the function if fstream throws an exception.
05:02
<@ToxicFrog>
Also, what do you mean by "out of PresetManager" anyways? Exceptions are thrown from inside function calls, not objects
05:02
< Consul>
Which I can do with if(!file) right?
05:02
<@McMartin>
Uh
05:03
<@ToxicFrog>
Umm
05:03
< Consul>
Okay, let me explain...
05:03
<@ToxicFrog>
If it throws an exception, it's not a condition you check
05:03
<@McMartin>
Your question betrays deep confusion about how exceptions work.
05:03
<@ToxicFrog>
It's an exception throw
05:03
<@ToxicFrog>
You either catch and handle it, or let it propagate upwards for one of your callers to catch and handle
05:03
<@ToxicFrog>
Yes, what McM said
05:03
< Consul>
PresetManager is a class to manage the storage, reading, and writing of presets for softsynths, samplers, and effects.
05:03
<@McMartin>
That's entirely behind the point.
05:04
<@McMartin>
You've done the equivalent of asking how to do a goto with for.
05:04
< Consul>
Within PresetManager is a function that takes a filename as an argument, and loads that preset file, and then parses it.
05:04
< Consul>
But, if it fails to load a preset file, it doesn't need to try to parse it.
05:04
< Consul>
So I'd like to be able to exit the function if that happens.
05:05
<@ToxicFrog>
...if you don't know that that's what exceptions do, what do you think they are?
05:05
<@McMartin>
And why are you doing them in C++ first ;_;
05:05
<@ToxicFrog>
That too
05:05
< Consul>
I'm still reading up on them, but online gives me either little information, or goes on about how they differ from C which helps me none.
05:06
<@McMartin>
I suggest, given your background, to learn them in Java first, where they are much more fundamental
05:06
<@ToxicFrog>
You should probably be reading up on exceptions as a concept
05:07
< Consul>
So you're saying that if the fstream object created in my loadPreset() function throws an exception, it kills the calling function as well? If so, that makes my life easy.
05:07
< Vornicus>
um
05:07
<@McMartin>
It kills any number of calling functions at once.
05:07
<@ToxicFrog>
The exception propagates upwards until caught or it leaves the program.
05:07
<@McMartin>
Until you reach a handler.
05:07
< Vornicus>
objects don't throw exceptions
05:07
< Vornicus>
functions/methods do.
05:07
<@ToxicFrog>
And objects don't throw exceptions, functions do.
05:07
<@McMartin>
Unless you consider an object's methods to be part of the object.
05:07
<@ToxicFrog>
Again - learn exceptions first.
05:07
<@McMartin>
But the code says "throw whatever" somewhere
05:07
< Consul>
So a function within fstream is throwing an exception. Okay, I can live with that.
05:07
<@ToxicFrog>
Then, learn C++ exceptions
05:07
<@McMartin>
But yes
05:07
<@McMartin>
Do not use exceptions blindly
05:08
<@McMartin>
They will fuck you over.
05:08
<@ToxicFrog>
We can help you with this, but you need to understand what exceptions are before you can use them~
05:08
<@ToxicFrog>
s/~/!/
05:08
<@McMartin>
And you clearly have no idea what they do, and your program will terminate with errors you do not understand.
05:08 * Vornicus uses exceptions very rarely.
05:08
< Consul>
Well, feel free to point me to a resource.
05:08
<@McMartin>
Looking through the Java tutorials now
05:08
<@McMartin>
As Java's use of exceptions is much closer to C++'s than the Other Use therefor.
05:09
<@ToxicFrog>
?
05:09
<@McMartin>
Short-circuiting tree recursion in functional languages.
05:09
< Consul>
Hey, if you tell me not to bother with using exceptions, I'll just blindly go forth and write my class.
05:10
< Consul>
But this fucking class, and many more after, is getting written whether you like it or not. :-p
05:10
<@McMartin>
Well, you should learn them.
05:10
< Consul>
Nobody in the Linux world is even bothering to try to do what I'm doing.
05:10
<@McMartin>
They're worth using for this problem, as, properly used, they are infinitely safer than optinonally checked return values.
05:10
<@McMartin>
You're mistaking the goal for the process again.
05:10
< Consul>
And so many of them are better programmers than I am.
05:11
< Consul>
So it's getting done.
05:11
<@McMartin>
I assure you that many programmers use exceptions - Azureus is full of them.
05:11
<@McMartin>
http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html
05:11
< Consul>
I have read and read, for hours now, all I can about exceptions, and this is how far I've gotten.
05:12
<@McMartin>
Important differences between Java and C++: C++ does not have the catch-or-specify requirement, and assumes by default that any function can throw anything.
05:12
< Consul>
It's all I've done the past two days.
05:12
<@McMartin>
C++ can throw any object of any class, or even primitive types
05:12
<@ToxicFrog>
Consul: the problem is not that exceptions are not the right tool. It's that you have no idea what they are or how to use them, probably in large part because you've been working from C++ specific tutorials, which teach not exceptions as a concept but how to use them in C++ specifically.
05:13
<@ToxicFrog>
Furthermore, one of the reasons this channels exists is to ask for help with stuff. This is Stuff. We can provide Help.
05:13
< Consul>
Well, so far I'm getting insulted and being told I'm too ignorant to do any programming.
05:13
<@McMartin>
No.
05:14
<@McMartin>
You're being told that you're trying to use a technique with which you are unfamiliar, and asking for help with the syntax.
05:14
< Consul>
Which is why I replied with why I'm torturing myself trying to learn this stuff when I'd rather be reading my LE Modesitt book.
05:14
<@McMartin>
We're calling you on the unfamiliarity and step one is always to learn the nature of the technique.
05:14
<@ToxicFrog>
...no, but if you insist on reading that into my words I'm going to go back to playing Grand Theft auto and writing a Set data type in Lua.
05:14
<@ToxicFrog>
Using exceptions.
05:14
<@McMartin>
Seriously, read the link I just gave.
05:14
<@McMartin>
And the sublinks.
05:14
<@McMartin>
That chapter goes into How Exceptions Work and what they do.
05:14
<@McMartin>
Once you've got that, we can talk about the differences between Java and C++, which are small.
05:15
<@McMartin>
And the syntax is nearly identical.
05:15
<@McMartin>
http://java.sun.com/docs/books/tutorial/essential/exceptions/definition.html is absolutely the most important, and without it, nothing we say will help.
05:15
< Consul>
Okay, sorry for the outburst, but please keep in mind, I'm on a mission here. I'm not just idly trying to be a pain in the ass. I'm out to truly accomplish something noticable.
05:16
< Consul>
And if I could spell noticeable, I might even get there.
05:16
<@McMartin>
Even if your only goal were to learn to use the tools, we'd help.
05:16
<@McMartin>
But you have to know how to use the tools, and that includes any tool used by the library.
05:16
< Consul>
Anyway, I'm reading that link now.
05:18
<@McMartin>
That should explain what exceptions do to your control flow.
05:21
<@McMartin>
My C++ is rusty, but I do seem to recall that there's some switch you have to throw to make library objects like fstream actually throw exceptions instead of just returning 0.
05:22
<@ToxicFrog>
The default behaviour of libstdc++ is indeed to return error codes rather than throwing exceptions.
05:22
<@ToxicFrog>
I do not know how to enable exception throws.
05:23
< Consul>
I know one can #include <exception> (or exceptions)
05:25
<@McMartin>
OK, so, it looks like vector and friends always throw.
05:26
<@ToxicFrog>
We're getting ahead of ourselves, though
05:26
< Consul>
And sorry for getting defensive back there. I've been getting several LAD people railing against me ever since that whole "Gigastudio discontinue/call for open-source sampler" debacle that I have to admit to starting.
05:26
<@ToxicFrog>
LAD?
05:26
<@McMartin>
Aha, here we go. http://www.cplusplus.com/reference/iostream/ios/exceptions.html
05:27
< Consul>
ToxicFrog: The usual "give up, you don't stand a chance" crap. You'd think they'd be more encouraging.
05:27
<@McMartin>
(It appears that "if (!file)" wouldn't have actually worked; iofstream works by setting badbit or failbit or various others. The "exceptions" property lets you set which of those throw exceptions when set)
05:27
< Consul>
I'm not trying to make Gigastudio here. First, LinuxSampler already did that to a degree, and second, I have some interesting ideas of my own.
05:28
<@McMartin>
That's a question of problem statement.
05:28
< Consul>
LAD = Linux Audio Developers
05:28
<@McMartin>
We've been known to be discouraging, but not over things like that.
05:29
< Consul>
Right now, I'm in bottom-up mode, creating classes that I know I'll need across any and all synths/samplers/effects made.
05:29
<@McMartin>
They tend to be things more like "I'm trying to write a human-level AI so that I can learn Java".
05:29
< Consul>
Myself and one other person, a Swede. He's handling the DSP and JACK-related stuff.
05:30
<@McMartin>
But for now, we're looking at bottom-up, so.
05:30
< Consul>
Well, he's handling DSP node and graph handling stuff, not actual DSP algorithms. We're not that far yet.
05:30
<@McMartin>
I'd suggest focusing on small, achievable goals and knitting them together later, but you're already doing that.
05:31
< Consul>
Yeah, and can you guess my current stumbling block? :-)
05:31
<@McMartin>
You're concerned about memory leaks and use-after-free, but you're not familiar enough with your implementation language for it to be easy to explain where you need to be careful.
05:32
<@McMartin>
But, if you're through with at least the basics, it will now be easier to explain.
05:32
<@McMartin>
... but first. How's your pointer-fu?
05:33
<@McMartin>
I'm guessing you're coming at this from a C background?
05:33
< Consul>
I can say I proudly got an A in my C++ for Engineers class. I learned how to make ADT classes, and that's about it.
05:33
<@McMartin>
ADT = Abstract Data Type?
05:33
< Consul>
Yeah
05:33
< Consul>
Operator overloading and that stuff.
05:33
<@McMartin>
When you made linked lists, was the next pointer a Node& or a Node *?
05:33
<@McMartin>
Or both?
05:33
< Consul>
I've been picking up on tamplates just fine. Those are pretty handy.
05:33
< Consul>
Hehe. We never got as far as linked lists.
05:34
< Consul>
We barely touched on pointers.
05:34
< Consul>
I picked up on as much of that as I could after.
05:34
<@McMartin>
(Be warned that there are some compatibility issues with templates across compilers. However, if the target is Linux, as long as it works on g++ you're fine.)
05:34
< Consul>
Mainly thanks to Anders (the aforementioned Swede).
05:35
<@McMartin>
OK.
05:35
<@McMartin>
But you've gone through new() and delete()?
05:35
<@McMartin>
And how they're different from declaring the variables as locals?
05:35
< Consul>
Yeah, I know that stuff, and I know how arrays actually work.
05:35
<@McMartin>
This project... it's C++ all the way through?
05:35
< Consul>
And that [] is actually a dereferencing operator.
05:36
< Consul>
Yup. We're doing these as header-only libraries.
05:36
<@McMartin>
I *strongly* recommend never using C-style arrays, then.
05:36
<@McMartin>
Stick with vector and deque and such.
05:36
< Consul>
Well, so far, I'm using map and list
05:36
<@McMartin>
Right.
05:36
< Consul>
No actual arrays, so far.
05:37
<@McMartin>
vector is in fact much, much closer to a classical array than C's "arrays" are.
05:37
< Consul>
I'll have to read up on vectors, then.
05:37 captainAweso [~tyler@Nightstar-7915.dsl.bell.ca] has joined #code
05:37
<@McMartin>
Thanks to overloading they look very much like C arrays, except for a few places where they behave like list.
05:37
<@McMartin>
However, when you try to write past the end of one, it throws an out_of_bounds exception instead of letting hackers take over your computer. =P
05:38
<@McMartin>
This is an important feature~
05:38
< Consul>
But I've already had occasion to make two templates. Having to do with returning the correct data type from information typedef'd from strings using boost::lexical_cast.
05:38
<@McMartin>
Boost I'm not familiar with.
05:38
< Consul>
They're fantastically well-documented.
05:38
<@McMartin>
But yeah, you'll need to be reasonably good with templates to handle using the C++ standard libraries.
05:38
<@McMartin>
Of which Boost, as I understand it, might as well be.
05:39
<@McMartin>
Anyway.
05:39
<@McMartin>
Stack variables declared in a function will be destroyed when they go out of scope.
05:40
<@McMartin>
Which is either (a) when you hit the matching } for the { that started the block that declared them, (b) when you return, or (c) when execution of the function abnormally terminates due to a thrown exception.
05:40
<@McMartin>
It is a horrific error to return a pointer or reference to a stack variable.
05:41
<@McMartin>
As an exception works its way up the stack, the variables will be destroyed as the stack frames are unwound.
05:41
<@McMartin>
However, if you've made any heap variables with new() and they haven't escaped (say, by having the pointer stuck in a list the caller knows about), then they will "leak" as the exception goes past.
05:41 AnnoDomini [AnnoDomini@Nightstar-29536.neoplus.adsl.tpnet.pl] has joined #Code
05:41 mode/#code [+o AnnoDomini] by ChanServ
05:42
<@McMartin>
This is a Bad Thing, and to be avoided, but it's only moderately bad. It means your system will need to be restarted occasionally as it is starts hogging resources.
05:42 * Vornicus is /so/ glad for auto-gc'd languages.
05:42 captainAweso [~tyler@Nightstar-7915.dsl.bell.ca] has quit [Quit: ]
05:42
< Consul>
McMartin: I'm kinda reading you and this tutorial at the same time. I'm still here. :-)
05:43
<@McMartin>
This is a supplement, as Java (a) does not have stack variables and (b) is garbage-collected meaning that the cleanup is always deferred.
05:44
<@McMartin>
(b) has some ugly wrinkles to it that as a C++ programmer you won't have to worry about - it's one of the reasons Java has finally and C++ doesn't.
05:45
<@McMartin>
So, to answer your initial, initial question, you have some design work to do for your interface.
05:45
<@McMartin>
You have a set of public functions you're exposing to the developer, as I understand it.
05:46
<@McMartin>
You need to decide what failures will result in an exception being thrown that the caller must catch, and what failures will return an easily ignorable fail code.
05:46
<@McMartin>
For the former, you can just declare the exceptions that it will throw. For the latter, you catch them yourself and, when caught, they do the requisite cleanup.
05:47
<@McMartin>
(For the latter, for instance, you might have something along the lines of "make this transformation if it's possible to do so" and have failure be "well, it didn't succeed, so the output won't be as nice but it's still there")
05:47
< Consul>
Well, for this class, I only have three: to tell the user that a file couldn't be found or opened, to tell the user that the file is of the wrong format/type, and to tell the user that a file cannot be written.
05:47
<@McMartin>
Is the "user" here a programmer using your code as a library, or a person sitting on the console typing stuff in?
05:47 * McMartin blinks
05:48
<@McMartin>
Oh. And if the former, is it OK if they use C?
05:48
< Consul>
Well, that's the odd part.
05:48
< Consul>
I'm thinking from the point of view of the end user, the one at the GUI of this cool new reverb or whatever.
05:48
<@McMartin>
Or, are you writing a library for the programmers and then also writing a thin shell around it for users, much like timidity++?
05:49
<@McMartin>
Aha.
05:49
<@McMartin>
However, you're not writing the reverb part?
05:49
< Consul>
Not yet, no.
05:49
< Consul>
:-)
05:49
<@McMartin>
Is it your intent that other people could link this part in for different apps?
05:49
< Consul>
That needs some research and trial and error. I have some info on how the Lexicon PCM70 reverb algo was done. :-)
05:50
< Consul>
Well, really, the point is to make it easier for me to make softsynths and effects.
05:50
<@McMartin>
OK then. I'd say that error messages are generally the responsibility of the user-level app.
05:50
< Consul>
With the side benefit of some header libs that others can use if they want.
05:50
<@McMartin>
Your responsibility is just to signal failure in some easy to detect way.
05:50
< Consul>
Exactly@!
05:50
<@McMartin>
For horrible, operation-cannot-possibly-proceed errors, I suggest exceptions.
05:50
< Consul>
I thought I had communicated that, but I guess I was wrong.
05:50
<@McMartin>
Well, it depends on the scale.
05:51
<@McMartin>
You've been talking about error dialogues and stuff
05:51
<@McMartin>
The hypothetical GUI app would make calls to your library, then catch the exceptions and put up appropriate dialog boxes.
05:51
< Consul>
As you can see, I'm suffering through this stuff until I can get to the good stuff, which is implementing complex math and graph algos into working plugins.
05:51
<@McMartin>
(All three of the errors you listed were essentially fatal for the operation, and so are exception-worthy.)
05:52
<@McMartin>
The hypothetical console app would catch the exceptions and dump appropriate error information to stderr.
05:52
<@McMartin>
And, the hypothetical C wrapper would catch the exceptions and turn them into error codes that it then returned, because C doesn't have exceptions to speak of.
05:52 olgagirl [~olgagirl@Nightstar-5683.w90-32.abo.wanadoo.fr] has joined #code
05:53
< Consul>
I guess my issue with PresetManager, then, is that I want to throw exceptions, but I don't want the object to get destroyed.
05:53
< Consul>
One PresetManager gets made per synth instance.
05:53
<@McMartin>
Whether the object gets destroyed depends on what the client intends to do.
05:53
<@McMartin>
Basically, if the code looks like this:
05:53
<@McMartin>
int main() { PresetManager p; p.blah(); .... }
05:54
<@McMartin>
Then p will be destroyed just before abort() is called if an exception is thrown.
05:54
< Consul>
But what I read on the throw() command is that when it's encountered and run, it runs the destructor of the object that the function that called the throw() is in.
05:54
<@McMartin>
Where did you read this?
05:54
< Consul>
Right.
05:54 olgagirl [~olgagirl@Nightstar-5683.w90-32.abo.wanadoo.fr] has quit [Quit: ]
05:54
<@McMartin>
Unless C++ exceptions are insanely broken, this should preserve p:
05:54
< Consul>
I can't remember. Probably cplusplus.com
05:55
<@McMartin>
int main() { PresetManager p; try { p.blah(); } catch (ConsulSynthFormatException csfe) { ... } p.leeg(); }
05:55
<@McMartin>
Where leeg doesn't throw exceptions
05:55
<@McMartin>
Then p should survive until main() returns.
05:56
<@McMartin>
Because you catch the CSFE before p's declaring scope goes away.
05:56
< Consul>
Okay, I think I see now.
05:56
<@McMartin>
On the other hand, if PresetManager::blah() had its own PresetManager defined inside it, that PresetManager would be destroyed upon throw(), just as it would be destroyed upon return.
05:57
<@McMartin>
Also, if blah() calls fstream::open which does the throw, and main() catches that too, then blah() doesn't need to do anything other than possibly declare that it throws those kinds of exceptions.
05:57
<@McMartin>
(And even then, such declarations are AIUI optional in C++; by default everything throws everything.)
05:58
< Consul>
As far as I know, fstream::open() just returns 0 upon failure.
05:58
< Consul>
So I guess I can do: if(!file) throw exp;
05:59
<@ToxicFrog>
IIRC whether fstream::open throws or not is configurable.
05:59
< Consul>
Within PresetManager::blah() that is
05:59 Shoukanjuu [~Shoukanju@Nightstar-27098.101.8.67.cfl.res.rr.com] has quit [Quit: Shoukanjuu]
05:59
<@McMartin>
fstream::open returns void.
05:59
< Consul>
I should read the docs on std::exception
06:00
<@McMartin>
If the open fails, then if your call to ios::exceptions had failbit set, an exception is thrown.
06:00
<@McMartin>
Otherwise you have to call ios::rdstate on your fstream to see if it's OK
06:00
<@McMartin>
(or, well, fstream::is_open)
06:00
< Vornicus>
failbit
06:00
<@McMartin>
YOUR BIT OF FAIL HAS BEEN DELIVERED
06:00
<@McMartin>
There's also badbit.
06:00
< Consul>
Heh
06:00
< Vornicus>
heh
06:03
< Consul>
Thank you much for the help. I realize I'm blinded by my passion, but I find it sad that it takes a guy with dismal C++ skills to finally try to code decent softsynths for Linux.
06:05 * McMartin is not a huge fan of C++ the language in general, honestly.
06:05
<@McMartin>
Though if you want real-time and decent code organization capability, it's still effectively your only choice.
06:05
< Consul>
Well, it's all I have that can do real-time.
06:05
< Consul>
Believe me, I would cream myself if I could do all I want in Python.
06:06
< Consul>
I'd have the preset file parser written already.
06:06
< Vornicus>
mmm, python...
06:06
< Consul>
In fact, the whole damn class would've been working two days ago.
06:06
<@McMartin>
Have you considered prototyping it in Python and having it output WAV files?~
06:07
< Consul>
In DSP, prototyping usually takes as much time as implementing. Usually, we protoype in something like Matlab, or in my case, Octave.
06:08
<@McMartin>
Fair enough.
06:08
< Consul>
Or Csound. That's a good prototyping environment for DSP algos.
06:08 * McMartin has unpleasant memories of EE 20 and Matlab.
06:08
< Consul>
I want my end result to be finished synths, not protoypes. :-P
06:09
< Consul>
Linux is full of prototypes.
06:09
< Consul>
Linux diehards would code an EQ plugin to take its settings input from a text file and run from the command line.
06:10
<@McMartin>
I note that you want one of those before you spend 6 weeks coding the wrong GUI.
06:10
< Consul>
People staying up until 3AM tweaking a mix need GUIs that show them clearly what's going on and what they're doing.
06:14
< Consul>
Can you tell I have a lot driving me?
06:14
< Consul>
I'm doing nothing less than accusing the entire LAD community that they have it wrong.
06:14
< Consul>
And I'm pushing myself to exhasution to prove it.
06:14
<@McMartin>
This is rarely a good move.
06:15
<@McMartin>
Just get it done and be done with it.
06:15
< Consul>
Well, I'm hoping I can prove myself enough to gain a few more developers.
06:15
< Consul>
But in the end, I just want to build tools that I would like to use.
06:15
<@McMartin>
Start with the library and a CLI wrapper and you'll be more likely to be able to recruit developers to expand the library and help wrap it in a GUI.
06:16
<@McMartin>
And you'll still need the console edition just to test your core.
06:17
<@McMartin>
And that's true with essentially every language, anyway.
06:18
< Consul>
Well, short test programs are part of the process.
06:19
<@McMartin>
Right, but link them into something scriptable and you have a complete app that can be readily turned into a much better complete app.
06:19
< Consul>
That's actually what I'm trying to avoid...
06:20
< Consul>
One of my tenets is that Linux, and Linux audio in particular, suffers some from code modularity, and that monolithic apps can be a good thing.
06:20
<@McMartin>
It's very hard to recruit people with an empty promise.
06:20
<@AnnoDomini>
Battletoads.
06:20
<@McMartin>
And if you don't design modularly you're just asking for trouble.
06:21
< Consul>
The source will be modular, yes. We're writing hrader classes, after all.
06:21
<@McMartin>
I wouldn't bother with dynamically loadable DSP plugins -- especially in C++ -- but you must split user interface from core logic.
06:21
< Consul>
header*
06:21
< Vornicus>
very must
06:21
<@McMartin>
If you don't your code will be an unmaintainable, unportable nightmare, and changes in the windowing system can break your core logic.
06:21
< Consul>
But in the end, I want programs that run without fifteen library dependencies.
06:21
<@McMartin>
Don't Do This.
06:22
<@McMartin>
You're already out of luck on that one.
06:22 * McMartin counts. libc, libc++, boost, esd/jack/alsa/etc., Qt/GTK...
06:22
<@McMartin>
That's five minimum.
06:22
< Vornicus>
libc and libc++ don't count.
06:22
< Consul>
Okay, maybe I'm not quite getting my point across...
06:23
<@McMartin>
You want it to be installable as a single package with minimal dependencies.
06:23
< Consul>
My engines are going to be designed for my GUIs.
06:23
< Consul>
Yes, they will be separate in logic.
06:23
< Consul>
But in the end, they will be designed to be together.
06:23
<@McMartin>
That's not terribly controversial.
06:23
< Consul>
From a usage perspective, not a code perspective.
06:24
<@McMartin>
However, modularity doesn't detract from this.
06:24
< Consul>
Tell that to the LinuxSampler people!
06:24
<@McMartin>
I'll just point at GIMP and Pidgin.
06:24
<@McMartin>
Both of which keep their logic in a separate library and the app "proper" as a shell around it.
06:24 * Vornicus should get back to fiddling with his pan/zoom code for VornMoO.
06:24
< Consul>
In other words, there will be no haphazard "slapping a GUI on a CLI app" with my stuff.
06:25
<@McMartin>
Your test scripts will be CLI apps.
06:25
< Vornicus>
So, no screen scraping?
06:25
< Consul>
Well, yes, for testing individual classes, sure.
06:25
<@McMartin>
You'll need it for testing each widget ahead of time, too.
06:25
< Consul>
Certainly.
06:26
< Vornicus>
You want to be able to talk to the thingy without going through text pipes?
06:26
<@McMartin>
You do not want to start testing the final application after you've stitched the whole GUI together because you won't know whether the bug is in the View or the Model.
06:26
< Consul>
But the end products will have little to do with the command line.
06:26
<@McMartin>
You're arguing for the Model to be designed around the needs of the View, which you believe LAD is ignoring.
06:26
<@McMartin>
Am I right so far?
06:27
<@McMartin>
They're, in your opinion, trying to write Photoshop/GIMP by putting a GUI around the ImageMagick utilities.
06:27
< Consul>
Hang on, I think I just saw a mouse...
06:27
<@McMartin>
As opposed to designing glib, which is designed for the express purpose of powering GIMP.
06:28
<@McMartin>
But which, thanks to its modular design, can also be used to be bound to other applications (which is, IIRC, what GIMP's Script-Fu is.)
06:29
< Consul>
Nope, just a cat sticking its paw under my bedroom door...
06:29
< Consul>
But I have seen mice lately, so better to check.
06:29
< Consul>
Anyway...
06:29 * Vornicus likes this: "They're, in your opinion, trying to write Photoshop/GIMP by putting a GUI around the ImageMagick utilities."
06:30
< Consul>
I don't think it's as simple as that.
06:30
< Consul>
But yes, I do argue that largely, the value of the GUI is shunned.
06:31
< Consul>
The GIMP is a bad example, as a graphics program without a GUI makes little sense, except for basic scriptable stuff.
06:31
<@McMartin>
Which is what the ImageMagick utilities are.
06:31
<@McMartin>
But, the GIMP is designed so that you can upgrade the GUI and the Logic Core independently, as is Pidgin.
06:31
< Consul>
And I can tell you, I am the wrong person to be on this crusade.
06:31
<@McMartin>
And this is in general a Good Thing, not least because the Logic Core tends to be more stable
06:32
< Consul>
I'm much more interested in the DSP side.
06:32
< Vornicus>
You /can/ do a great deal of the stuff the GIMP does using ImageMagick... but you wouldn't want to.
06:32
<@McMartin>
But to hear you rant about this their problem is that they're essentially using the wrong primitives.
06:32
<@McMartin>
...otherwise you could hack a good chunk of stuff into Audacity or something.
06:32
< Consul>
No, not quite that, either...
06:33
< Consul>
It's more the general attitude.
06:33
< Consul>
As if they've given up on Linux ever being more than a shadow of the "pro" Windows and Mac world.
06:33
<@McMartin>
(Since I am unfamiliar with the problem domain: What key GUI features does Audacity lack for sound editing?)
06:33
< Consul>
Our best softsynth hasn't been updated since 2003.
06:34
< Consul>
No, sound editing has nothing to do with it. I'm talking about synthesis, sampling, and effects.
06:34
<@McMartin>
How are effects and sampling different from editing?
06:34 * Vornicus ponders: writing a game like Space Empires as a call/response console app, sort of, and then wrapping the gui around that; has the advantage of making bots and gui rewrites /really/ easy...
06:34
<@McMartin>
(total n00b here, sorry. Except for fiddling with MODs as a teenager.)
06:34
<@McMartin>
Vornicus: Isn't that basically what FreeCiv does?
06:35
< Vornicus>
McM: ...a true point.
06:35
< Consul>
McMartin: it's the difference between loading a picture to edit it, and creating the picture in the first place.
06:35
<@McMartin>
Consul: Also: why does synthesis have to be real-time?
06:35
< Consul>
McMartin: Because musicians are used to hearing the note when they press the key.
06:35
<@McMartin>
Consul: I'm getting the feeling I don't know what "effects" amd
06:36
<@McMartin>
and "sampling" even are in this context.
06:36
< Consul>
Effects are things like reverb, flanging, things that alter a signal in real time.
06:36
< Consul>
which is NOT the same as editing a wave captured as a file.
06:36
< Vornicus>
Whammy bar!
06:36
<@McMartin>
Right. I was thinking more like volume normalization, etc
06:37
< Consul>
Synthesis is the generation of waveforms from math.
06:37 * Vornicus ... doesn't know what the whammy bar does.
06:37
< Consul>
And then further processed.
06:37
<@McMartin>
OK. And sampling? Which I read as "making the recordings you eventually base your synthesis on"
06:37
<@McMartin>
Well, if you're doing wavetables.
06:37
< Consul>
Sampling is like synthesis, just starting with recorded material.
06:37
<@McMartin>
OK, that clears up my confusion.
06:38
<@McMartin>
Presumably the recording of the material just requires a microphone, a good studio, and the instruments in question
06:38
<@McMartin>
And then a burner for the several DVDs of AIFFs or whatever that result
06:38
< Consul>
Well yeah, if you have the luxury of that equipment and setting.
06:38
< Vornicus>
I get the impression that what Consul wants is all that shit that's in the mixing room.
06:38
<@McMartin>
Well, if you lack those, you go and buy the DVDs full of AIFFs after someone else recorded them.
06:38
< Consul>
What I want is Native Instruments for Linux.
06:38
< Consul>
nativeinstruments.com
06:39
< Vornicus>
nxdomain
06:39
<@McMartin>
Hm.
06:39
<@McMartin>
OK, I'd split the problem into two, possibly three parts.
06:39
< Vornicus>
ah. native-instruments.com
06:39
< Consul>
They're instruments, in real time, that run on a computer instead of in external hardware.
06:39
<@McMartin>
Part (1): Enough working DSP to be able to fabricate the sounds you want, to spec, through an API.
06:40
< Consul>
So I can plug my MIDI keyboard into my computer, hit a note, and hear it immediately.
06:40
<@McMartin>
This is general enough that in addition to shoving it out the speaker immediately it should be trivial to write it out as raw PCM.
06:40
< Consul>
We have library headers for that stuff planned.
06:40
<@McMartin>
Part 2: Parse various kinds of input, including MIDI, to be able to do stuff in real time, linking those headers.
06:40
< Consul>
I took on the preset library because I *thought* I could handle it. Hah!
06:41
< Consul>
JACK already does that.
06:41
< Consul>
Anders has a working JACK class.
06:41
<@McMartin>
Part 2.5: For those of us with crappy computers and minimal musical talent, the ability to write programs that turn our sheet music into actual music. You don't want to do that. I want that lots and would totally write it myself if you don't.
06:41
<@McMartin>
Part 3: GUI with the knobs for tweaking effects in real-time.
06:41
< Consul>
I think Rosegarden can do that now...
06:41
<@McMartin>
Part 4: Extended to full mix control a la Cakewalk/Garage Band/etc.
06:42
<@McMartin>
Consul: By hypothesis the instruments all suck though.
06:42
< Consul>
That's already Ardour's domain.
06:42
< Consul>
I want to write the instruments.
06:42
< Consul>
Because that's the one weak point in Linux audio, and that's the one point nobody seems to care about.
06:43
<@McMartin>
So, if you write the instruments and have a "play this note" API where "play" can mean "dump as AIFF or WAV", that's actually more important than everything else.
06:43
< Consul>
If I write these instruments as JACK clients, then any Ardour user can use them, any Rosegarden user can use them.
06:43
< Consul>
No, JACK handles output, too.
06:43
< Consul>
You see, that's the thing. So much amazing work HAS been done, and yet, so much remains.
06:44
< Consul>
No big deal in and of itself, but I didn't much like being told it can't be done by the very guy who pulled off Ardour and JACK.
06:44
< Consul>
You'd think of all people, he'd appreciate an upstart.
06:44
< Vornicus>
So, in short
06:44
< Vornicus>
You want to Show Them All.
06:45
< Vornicus>
Especially Those Fools At The Institute.
06:45
< Consul>
Yes, and no.
06:45
< Consul>
Yes, because I think some people need a kick in the butt.
06:45
<@McMartin>
From what you're telling me, it seems like a lot of the GUI work is incidental.
06:45
< Consul>
And no, because in the end, I want these tools to use myself to make music.
06:45
<@McMartin>
Rosegarden already exists, but its output sucks because one of its libraries is crap and nobody wants to upgrade it
06:45
<@McMartin>
Cue, well, you.
06:46
< Consul>
And believe it or not, starting with JACK clients is starting small.
06:46
< Consul>
Because JACK routes all the audio and MIDI, and the app can focus on the engine and GUI.
06:47
< Consul>
The "showing them all" bit is just a motivator.
06:47
<@McMartin>
I think my question is...
06:47
< Consul>
In the end, I really just want to make the tools I would like to use.
06:47
<@McMartin>
Once you have a JACK client, why aren't you done?
06:47
< Consul>
Well, it doesn't stop with just one effect, or one synth, does it?
06:47
<@McMartin>
Er
06:47
<@McMartin>
"Why is there a GUI component to your Master Plan"
06:48
< Consul>
Because interfaces are important to musicians.
06:48
<@McMartin>
Let's try this again.
06:48
<@McMartin>
Rosegarden exists. Ardour exists. Are you trying to replace them, or extend them so that they don't suck anymore?
06:48
<@McMartin>
And does the latter require you to do any GUI work?
06:49
< Consul>
We have a domain issue here.
06:49
< Consul>
The problem domain I'm in has nothing to do with Ardour or Rosegarden.
06:49
< Consul>
Nothing I make will lessen the requirement of either program.
06:49
<@McMartin>
(Incidentally, Rosegarden or something like it is something I've been looking for for years)
06:49
< Consul>
Because they have nothing in common.
06:50
<@McMartin>
(So thanks for that)
06:50
< Consul>
Ardour is a multitracker and mixer.
06:50
< Consul>
It doesn't synthesize anything.
06:50
< Consul>
It records, plays back, mixes.
06:50
< Consul>
It doesn't synthesize, because that's not its problem domain.
06:50
<@McMartin>
And Rosegarden is a score editor.
06:51
< Consul>
Rosegarden also multitracks.
06:51
<@McMartin>
OK, so, I guess I don't understand the toolchain.
06:51
<@McMartin>
I'm imagining it as, say, Rosegarden -> MIDI file -> your tools -> WAV file.
06:52
< Consul>
Ardour would record the output of my synths as tracks.
06:52
< Consul>
In real time.
06:52
< Consul>
So, I open Ardour, I open my synth, I play my synth via MIDI, Ardour records the output, in real time.
06:53
<@McMartin>
OK.
06:53
< Vornicus>
So Rosegarden -> Midi -> ConsulSynth -> Ardour -> WAV
06:53
< Consul>
Effects can fit in anywhere, but again, they're external to Ardour.
06:53
< Consul>
You could do that if you wanted, but Ardour is getting MIDI integration come version 3.
06:54
< Consul>
Which means that Ardour plays the MIDI file, and my synth would turn that MIDI to audio, then Ardour would record it again.
06:54
< Consul>
It's just like a studio...
06:54
<@McMartin>
There is, however, one crucial difference.
06:54
< Consul>
Ardour is the reel-to-teel tape deck.
06:54
<@McMartin>
Right.
06:54
< Consul>
And the mixing desk.
06:54
<@McMartin>
The thing is, I've often done computational music.
06:54
< Consul>
The instruments are separate.
06:55
<@McMartin>
Which generates a MIDI sequence directly.
06:55
<@McMartin>
Or I step-record, because my computer is slow and weak.
06:55
<@McMartin>
So if I had something where I could write a MIDI Level 1 parser and have it turn it in non-real-time into a properly synthesized piece, this would be wicked cool by my lights.
06:56
<@McMartin>
But I'm not sure if that's even a chunk of your toolchain.
06:56
<@McMartin>
It sounds like not.
06:56
< Consul>
If you have a MIDI file, that would load into a sequencer which would route the MIDI messages to my synth.
06:56
<@McMartin>
So, like timidity?
06:56
< Consul>
Then the synth would output an audio stream into a recorder, like Ardour.
06:56
<@McMartin>
(Or is timidity itself just a softsynth?)
06:56
< Consul>
Like timidity in basic concept.
06:56
< Consul>
But it would be real time.
06:57
<@McMartin>
Well.
06:57
<@McMartin>
If your computer is fast enough.
06:57
< Consul>
Tmidity is kind-of a hold-over from when computers couldn't really do real-time synthesis.
06:57
< Consul>
Which now, is almost trivial.
06:57
<@McMartin>
...
06:57
<@McMartin>
So, uh, my computer is only 1Ghz
06:57
< Consul>
To the point that soon, even the non RT-safety of Python won't matter.
06:58
<@McMartin>
There's always a delay of at least 100ms even with something like Cakewalk when I have it drive a softsynth
06:58
< Consul>
1Ghz can run a softsynth or two in real time.
06:58
<@McMartin>
And that fucks me up no end.
06:58
< Consul>
Aha!
06:58
< Consul>
That's latency!
06:58
< Consul>
Which is a whole other issue.
06:58
<@McMartin>
OK, I've misunderstood again~
06:58
<@McMartin>
Latency + lack of talent = I always have to step-record.
06:59
< Vornicus>
Very easy to add more latency.
06:59
< Consul>
Well, latency can be solved. I also maintain that lack of talent can be as well.
06:59
< Vornicus>
Very, very, very hard to take some away.
06:59
<@McMartin>
So given that, the toolchain I'd use for doing a song would be "compose on whatever, get the score, then ram it through in batch"
06:59
< Consul>
I don't know if you'd want to use what I hope to make or not.
07:00
<@McMartin>
I'm not clear either, which is why I'm urging for there to be a component that I could bend to my will~
07:00
< Consul>
My only goal is to make the tools I want to use.
07:00
< Consul>
If I can, I want to do it right.
07:01
< Consul>
But I am limited by my skill, and by my narrow goals.
07:01
< Consul>
I have a specific problem domain I'm handling, and I won't be straying from it.
07:01
< Consul>
It sucks having passion and no skill.
07:02 * McMartin nods
07:02 * McMartin is somewhat, as you may have noticed, in the same boat wrt music.
07:02
<@McMartin>
That said, my recommendation is to look at the existing toolchains, and figure out a way to hook into what's already there with the minimum possible effort.
07:03
< Consul>
JACK is exactly that.
07:04 * McMartin eyes Fedora.
07:04
< Consul>
I use Ubuntu Studio.
07:04
< Consul>
64 bit, to be precise.
07:04
<@McMartin>
Why is jack not installed, and why does Rosegarden not require it.
07:05
< Consul>
Well, Rosegarden was around before JACK, so it supports straight out to ALSA, too.
07:05
<@McMartin>
Yes, but that's not the point.
07:05
<@McMartin>
Fedora is generally very good about setting things up so that when you say "install this app" it grabs everything you need to have that app run right automatically.
07:06
<@McMartin>
Oh hey, it *is* installed. It just isn't running or ALSA doesn't know about it or something.
07:06 * McMartin mutters.
07:07
< Consul>
JACK is a daemon.
07:07
<@McMartin>
So is alsa.
07:07
<@McMartin>
JACK is installed, but for whatever reason, it is not running, or Rosegarden is not detecting it.
07:07
< Consul>
Do you have qjackctl?
07:07
< Consul>
That's a GUI to manage JACK settings, start and stop it, monitor its performance, and the like.
07:08
<@McMartin>
The dependencies listed for rosegarden4 that I did not have were:
07:08
<@McMartin>
OpenEXR-libns, fftw, ilmbase, kde-filesystem, kde-settings, kdelibs-common, kdelibs3, ladspa, liblo, liblrdf, oxygen-icon-theme, and raptor.
07:10
< Consul>
Kinda surprised you didn't already have fftw...
07:11
< Consul>
Raptor is an RDF library.
07:11
< Consul>
That's Steve Harris's doing. :-)
07:12
< Consul>
He introduced RDF to the Linux Audio world.
07:12
< Consul>
LADSPA is a meat-and-potatoes plug-in spec.
07:13
< Consul>
It's for effects only, not synths, and doesn't support custom GUIs.
07:13
< Consul>
On the plus side, it's easy to develop for, and for meat and potatoes effects like chorus, flange, reverb, and the like, it works quite well.
07:14
< Consul>
Well, I'm told it's easy to develop for.
07:18
<@McMartin>
Ha *ha*, got it
07:19
<@McMartin>
I need to start timidity -iAD, then start jackd, then start Rosegarden, and then it all works.
07:19
< Consul>
Argh
07:19
< Consul>
Can anyone please voice me?
07:19 mode/#code [+v Consul] by McMartin
07:19
<@McMartin>
Done
07:20
<+Consul>
Thanks!
07:20
<+Consul>
http://flickr.com/photos/dmlandrum/1572472904/sizes/l/in/set-72157602296885071/
07:20
<+Consul>
The doilies (which were just dishtowels put there temporarily) have since been replaced with vibration iso pads.
07:21 mode/#code [+oo Consul Vornicus] by Vornicus
07:21
<@Consul>
Thanks
07:25
<@Consul>
Anyway, hopefully that picture gives an idea of how serious I am.
07:25
<@Consul>
I built that desk myself to accommodate this keyboard.
07:25
<@Consul>
Keyboard as in MIDI keyboard.
07:26
<@Consul>
Which weighs about 100 pounds, by the way.
07:27
<@Consul>
True full hammer action, same mechanism as a grand.
07:27
<@Vornicus>
Impressive.
07:29
<@Consul>
The action is pretty noisy, though.
07:29
<@Consul>
Mechanically, I mean.
07:30
<@Vornicus>
Like, you can hear it, or it shows up in the, uh, signal?
07:30
<@Consul>
Just mechanically.
07:30
<@Consul>
The hammers banging the sensors.
07:30
<@McMartin>
OK, now dosbox is hanging the shit out of X.
07:31
<@Consul>
Vornicus: All it outputs is MIDI messages.
07:33
<@Consul>
are*
07:33
<@Consul>
:-/
07:33
<@Consul>
It's getting late.
07:33
<@Vornicus>
right, but I mean, uh.
07:33 * Vornicus tries to describe.
07:34
<@Vornicus>
Do MIDI messages give off, like, real time press-strength values, or...?
07:35
<@Consul>
Yeah
07:35
<@Consul>
This one has polyphonic aftertouch.
07:35
<@Vornicus>
I don't even know what that is.
07:35
<@Consul>
And it has true strike force sensing, rather than velocity.
07:36
<@Consul>
Though it works pretty much the same as velocity, so that's what they call it.
07:36
<@Vornicus>
I guess what I'm looking for is, if I press a key on the keyboard, can I get a graph of how hard I've been pressing the key, in real time?
07:36
<@Consul>
It also has release velocity (how fast you release the key).
07:36
<@Consul>
Yep
07:36
<@Consul>
That's aftertouch.
07:37
<@Vornicus>
okay.
07:37
<@Consul>
Now, there are two kinds of aftertouch...
07:37
<@Consul>
Monophonic, or channel, aftertouch only sends one aftertouch signal, the one being pressed hardest, usually.
07:38
<@Consul>
So, you could be pressing a fistful of notes, and only one aftertouch signal gets sent.
07:38
<@Consul>
Channel aftertouch is the most common type.
07:38
<@Consul>
This keyboard has polyphonic aftertouch, wherein each note sends its own aftertouch signal.
07:40
<@Vornicus>
cool.
07:40
<@Consul>
Most synth engines, including hardware ones, can't even use it.
07:40
<@Consul>
The NI stuff can.
07:41
<@Consul>
And I seem to recall the older 80s Yamaha FM synth modules could.
07:41
<@Vornicus>
okay. So part of this is modding the existing synth engine to use aftertouch?
07:42
<@Consul>
Well, our libraries will allow the use of any midi controller anywhere, if all goes right.
07:42
<@Consul>
I definitely have poly aftertouch in mind.
07:45
<@Consul>
I'm really getting ahead of myself, though, and the earlier joke about "wanting to show them all" kinda hit home, and makes me think I should tone myself down a little.
07:53
<@Vornicus>
Generally you should aim at little changes first.
07:54
<@Consul>
Well, things like classes for OSC, for DSP graphs, for presets, can be written and tested individually.
07:55
<@Consul>
I'm coding a header-only library only because I don't know how to make dynamic ones.
07:56
<@Consul>
So it limits me to C++, but I can live with that, I suppose.
07:56
<@Consul>
It certainly could be worse.
07:56
<@Vornicus>
Doesn't need to be dynamic if it's header-only.
07:56
<@Vornicus>
if it's not, rather
07:56
<@Consul>
Well, we decided on this approach based on the Boost libs.
07:56
<@Consul>
We figured if they can do it...
07:56
<@Vornicus>
Which are header-only because that way everything gets inlined.
07:57
<@Consul>
Was there a reason for going that route?
07:58
<@Vornicus>
Inlining means no call overhead, which can be significant.
07:58
<@Consul>
Ah... In that case, it's a good reason for us to go this route as well.
08:00
<@Consul>
Or not.
08:00
<@Consul>
I don't know.
08:00
<@Consul>
Nor do I care anymore.
08:00
<@Vornicus>
It's not horribly significant.
08:01
<@Vornicus>
The advantage of using non-header-only code is that it makes it a lot easier for someone to figure out what your API looks like.
08:03
<@Vornicus>
(and also you can hide private functions away so they're not exposed to hte outside world)
08:09
<@Consul>
I really need to hit the sack now. Night!
08:10
<@Vornicus>
ni.
08:19
<@McMartin>
I'm not sure if, by "header only", he didn't actually mean "we aren't making it an .so"
08:19
<@McMartin>
As in "you have to include the headers to use it"
08:19
<@McMartin>
As opposed to, say, dlopening stuff.
08:45 Vornicus is now known as Vornicus-Latens
09:10 You're now known as TheWatcher
09:58 Vornicus-Latens [~vorn@Admin.Nightstar.Net] has quit [Ping Timeout]
11:29 Thaqui [~Thaqui@Nightstar-13764.jetstream.xtra.co.nz] has left #code [MORE constitution LESS destitution MORE pros...perity.]
11:34 You're now known as TheWatcher[afk]
11:42 Attilla [~The.Attil@92.20.0.ns-26568] has joined #code
11:42 mode/#code [+o Attilla] by ChanServ
13:48 Consul [~darren@Nightstar-473.dsl.sfldmi.ameritech.net] has quit [Ping Timeout]
13:48 Consul [~darren@Nightstar-1618.dsl.sfldmi.ameritech.net] has joined #code
14:44 AnnoDomini [AnnoDomini@Nightstar-29536.neoplus.adsl.tpnet.pl] has quit [Ping Timeout]
14:45 AnnoDomini [AnnoDomini@Nightstar-29536.neoplus.adsl.tpnet.pl] has joined #Code
14:45 mode/#code [+o AnnoDomini] by ChanServ
16:02
< Consul>
Someone needs to make a t-shirt: "The LHC detroyed the Earth and all I got was this lousy t-shirt."
16:33 Syloq [Syloq@Admin.Nightstar.Net] has joined #code
16:34 Syloq is now known as Syloqs-AFH
16:46 You're now known as TheWatcher
16:51 Shoukanjuu [~Shoukanju@Nightstar-27098.101.8.67.cfl.res.rr.com] has joined #code
17:45 Vornucopia [~vorn@Admin.Nightstar.Net] has joined #code
17:45 Vornucopia is now known as Vornicus
19:14 Consul [~darren@Nightstar-1618.dsl.sfldmi.ameritech.net] has quit [Quit: Ex-Chat]
19:33 Shoukanjuu [~Shoukanju@Nightstar-27098.101.8.67.cfl.res.rr.com] has quit [Quit: Shoukanjuu]
20:06 Shoukanjuu [~Shoukanju@Nightstar-27098.101.8.67.cfl.res.rr.com] has joined #code
20:22 Consul [~darren@Nightstar-1618.dsl.sfldmi.ameritech.net] has joined #code
20:29 You're now known as TheWatcher[afk]
20:47 AnnoDomini [AnnoDomini@Nightstar-29536.neoplus.adsl.tpnet.pl] has quit [Ping Timeout]
20:49 AnnoDomini [AnnoDomini@Nightstar-176.neoplus.adsl.tpnet.pl] has joined #Code
20:49 mode/#code [+o AnnoDomini] by ChanServ
21:40 You're now known as TheWatcher
22:40
<@jerith>
I have a race condition in my tests. :-/
22:43 You're now known as TheWatcher[T-2]
22:43
< Consul>
Who won?
22:44
<@jerith>
The spiders.
22:45
< Consul>
Oooh, we'd better mount a counter-offensive.
22:45
< Shoukanjuu>
>_>
22:47 You're now known as TheWatcher[zZzZ
22:47 You're now known as TheWatcher[zZzZ]
23:08
< Consul>
Can I initialize a C++ string to a null string when I declare it? I remember trying this once, and it not working for some reason. | string str = ""; // something like that
23:20
< Consul>
nm, I have a better solution to the whole issue. Thanks anyway.
23:22 * Vornicus examines linear programming, can't believe it's actually that easy.
23:22
<@jerith>
It is.
23:23
<@jerith>
Nonlinear programming is rather more difficult.
23:30
< Vornicus>
:P
23:31
< Consul>
Superlinear programming is the really tough stuff.
23:32
< Consul>
The problem is, I say that thinking it's a dumb joke, but there might be, unbeknownst to me, a real form of programming called "superlinear."
23:33
< Consul>
And what do you know, there is, sort-of.
23:37
<@ToxicFrog>
Vornicus: what do you mean by "linear programming" here?
23:38
<@ToxicFrog>
Oh, nvm. Linear function optimization.
23:44
< Vornicus>
indeed.
23:54 AnnoDomini [AnnoDomini@Nightstar-176.neoplus.adsl.tpnet.pl] has quit [Quit: Drive me closer, I want to hit them with my sword!]
--- Log closed Sun Aug 03 00:00:31 2008
code logs -> 2008 -> Sat, 02 Aug 2008< code.20080801.log - code.20080803.log >