If I may ask you and others on here, how does this stack up against fltk? I'm going to be working on a demo of making a seperate a gui to control csound from the new csound api, and am trying to figure out which would be best. I had been thinking fltk because csoundav already uses fltk so many csounders know it and might have guis they could move from within csound to without. But I know very little about guis. I'd like something that is also pretty easy to make new guis quickly if you have a functioning template. I suspect you are being overly modest, but is that because you think you didn't design it well, or because it is a specific kind of sequencer? My interests are in that style of sequencer, but I'm not actually interested in writing it to do midi output, but again rather to output to csound through the api. ( If people want midi output to hardware instruments too, it's trivial to do that from a csound instrument with all kinds of bells and whistles. ) If you have the time, can you say what you don't think was good about the design? I was under the impression that Softwerk does a good job of making real time use the first priority, which is also what I want. If you think I should look at other code for learning real time timing critical programming for a live sequencer, can anyoune suggest a good project to look at? Thanks Iain

thats odd, i'll check it. i use pkg-config to get the libs needed, and they should be included. on my system they show up automatically. what does pkg-config --cflags gtk+ output for you? i only include C++ libraries because i am not willing to deal with compilation issues raised by the way C++ works on linux. i've been bitten too many times with this, and i'm just not prepared to deal with it again. as i've said with ardour, if someone submits a patch to add a configure-time option to avoid compiling+using the included libs, i will merge it, but i will not support the result. glad to be of service. --p

oh dear, i seem to have some gnome-config nonsense that allowed "gtk" to work. fixed in my source. which c++ projects are you referring to?

the problem with gtkmm and sigc++ is that they are not part of many (most?) distributions. as a result, the way they were built is basically unknown. did the user do it? did they get it from freshrpms? thac? some slack source? once they are both bundled with most distributions, the uncertainty over the build technique will be gone, and i'll feel comfortable using the system ones. the situation for Qt, for example, which is also C++, is quite different: it is installed as a standard on almost every distribution. ardour installs no shared libs, specifically to avoid this. it links statically against its internal libraries, just like softwerk does. --p

this is where the special magic of C++ kicks in. what if they were compiled with gcc3.4? or gcc2.95?or gcc-anything-other-than-what-the-user- is-about-to-compile-softwerk-with? what if some idiot used -fno-exceptions when building the libraries (its been known to happen)? there are a few other scenarios. because C++ has no standard ABI (despite the claims of the g++ project that "version <insert number> is the stable ABI ... oops") things don't fit together the way they do with C. you have to be assured of the compiler version and flags for binary library to be useful. quite :) --p

they are text entry widgets. just click or use TAB/right or left arrows to navigate, then enter new values. excellent idea. mousewheels didn't really exist widely when i started this, and i tend to still forget about them.

The trigger dialog wasn't showing anything (channel select, note select, etc.) making it pretty unusable. Looking at the code, all the -9999's for vpadding in trigger_ui.cc (starting at line 123) seem to be making everything disappear. New version of gtkmm has a different behaviour maybe? Anyway, I changed the -9999's to 5, the same as the horizontal padding, and it looks fine to me (not to mention actually now works) Patch attached, same goofy format as the last one -DR-