Re: [Qutecsound-users] Comments on QuteCsound 0.5.0

[Andres C. <man...@gm...>]

Hi,

On Sat, Apr 3, 2010 at 4:16 PM, Louis Cohen <do...@jo...> wrote:
> Hi, Andres,
>
> I do have performance problems (running MacCsound and Csound 5.0.9),
> but I'm not sure that the problem is in Csound or with widgets. Here's
> what I've done to avoid problems:
> 1. I read and update widget values once in every 5 k-cycles.
> Previously I was doing this every k-cycle.
> 2. I keep track of how many instruments are running at once. If the
> number exceeds a certain threshhold (controlled by a widget!) my code
> will simply not instantiate new instruments until the active number
> eventually falls below the threshhold. I also display the current
> count of active instruments, and can therefore adjust the threshhold
> if I need to.

There should be a significant improvement between QuteCsound and
MacCsound in terms of performance on an Intel machine, since the old
version of MacCsound (which goes with that version of Csound), is
built for PPC, so it must run under Rosetta, and this has a high
performance penalty. I would expect a bigger difference, which means
that things may still be able to improve in terms of performance for
QuteCsound.

> In this way, with MacCsound and 5.0.9, I could have 18-20 instruments
> creating sound signals at once. With QuteCsound and 5.10, it looks
> like that threshhold is about 23-25 (on an Intel machine.)
> BTW, you can hear a recent solo performance I made with MacCsound and
> 5.0.9. It will give you an idea of how much sound I can produce at
> once: http://www.jolc.net/lcpublic/ruccaspages/advent2010/

Thanks, I enjoyed that. It's quite elaborate as well for being so
performance driven.

> It looks like any line containing a colon (:) is being identified as a
> navigation point. This includes colons in comments.
> As for what a user could do to create a navigation point, it seems no
> harm is done by a user inserting lots of labels, but if this has
> unwanted side-effects, how about allowing comments with a special
> character sequence, such as ";;>>"?
>

That's a good idea. I think I'll just use the two semicolons, as it is
enogh and doesn't look so cryptic.

> I don't know what language you're using for QuteCsound, but I know
> with Java I can write code to make any element the active element. So
> if the user selects a menu item, my Java code can detect that and then
> ensure that the appropriate window immediately becomes the focus.
> Also I don't think that having a widget ignore keyboard events is the
> best solution, since some widgets are fields the user needs to type
> into.
> I just tested my improviser: I can drag on a scroll number and sense
> keyboard keys simultaneously -- no problem, same for dragging a
> controller while typing. However if I click and hold a menu, I cannot
> sense the keyboard. Also, as I mentioned, once I release the menu, it
> remains selected (you can see a highlighed border around the widget)
> and keystrokes do not go to Csound until I click the window.
>

I use the Qt C++ toolkit, and the issue is more with the way the
widgets consume the keyboard events. I think this can be properly
fixed to the expected behavior. (In most other applications, you would
wnat the widget to consume the key press, rather than propagate it
across the application, so I guess that's why they do that by
default...)

>  > Incompatibilities between MacCsound and QuteCsound:

> I agree this should no longer be fixed, but it would be nice to issue
> very clear warnings to MacCsound users. Perhaps you could sense
> whether QuteCsound is opening a MacCsound file and issue a warning as
> the file opens?

It's actually not easy to tell whether the file was created by
MacCsound or QuteCsound, as there is no place in the format where this
can be specified... So I think it's better to put this in the
documentation and release notes as known issues.

> If you'll be allowing editing of XML, I hope you'll be providing
> enough indentation to make the code easy to read. The use of XML is
> probably the right decision because the tags provide useful
> documentation to the user. Also I can see that it could make it
> possible to easily extend the widget base or even change the widget
> platform in the future. But it sure is verbose! One thing you could do
> is to "cheat" a little bit by combining parameters: so instead of:

Qt can easily produce xml with any indentation, but the default looks
like what I showed you, which I think is good enough.

Cheers,
Andrés