[Qutecsound-users] first use of qutecsound-f : comments

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Qutecsound-users] first use of qutecsound-f : comments

Louis Cohen-3
I'm using QTCS-f 0.6.0 beta ("-incQT" version), downloaded from  
sourceforge June 20 2010.

Environment: Mac OSX 10.5.8, Mac Pro, intel quad-core.

Many aspects of this version of QTSC work very well. My improvising  
software runs well after starting and stopping it several times.  
However, there are some problems that I observed:


Although I can see in JEdit that widgets are now stored in xml format,  
I can find no way to edit or view this xml code within QuteCsound.

I tried editing the xml for a display widget, using Jedit. Even though  
I then loaded the modified file with QuteCsound, it seems that my edit  
was ignored. I changed the precision of a field from 3 to 1 (and also  
from 3 to zero.) But the displayed precision remained the same. Here  
is the text (after I edited it):

<bsbObject version="2" type="BSBDisplay">
   <objectName>minutesdisplay</objectName>
   <x>893</x>
   <y>536</y>
   <width>23</width>
   <height>33</height>
   <uuid>{af8a2eef-68b8-40cd-b303-dcf76068a436}</uuid>
   <visible>true</visible>
   <midichan>0</midichan>
   <midicc>-3</midicc>
   <label>38.000</label>
   <alignment>left</alignment>
   <font>Lucida Grande</font>
   <fontsize>18</fontsize>
   <precision>1</precision>
   <color>
    <r>192</r>
    <g>17</g>
    <b>30</b>
   </color>
   <bgcolor mode="nobackground">
    <r>255</r>
    <g>255</g>
    <b>255</b>
   </bgcolor>
   <bordermode>noborder</bordermode>
   <borderradius>1</borderradius>
   <borderwidth>1</borderwidth>
  </bsbObject>

At first glance, widget properties appear to be the same as in 0.5.0.  
For example, for knobs, none of the many characteristics of knobs that  
I read about in the QuteCsound xml specs for widgets are available in  
the properties window, and the "resolution" of a knob displays no  
editable field. Another example: text display fields that display  
numerical values cannot be customized to specify precision of  
numerical displays (even if I edit the xml, as above.)

The controller widget has a slightly different behavior in this  
version compared to last version. It seems to behave more like the  
corresponding widget in MacCsound - a click, without dragging, moves  
the controller to new coordinates (as it does with MacCsound). In QTCS  
0.5.0 it was necessary to click AND drag in order to change the  
coordinates of the cursor.

The widget window remains as before, not a true window, therefore must  
be manually sized by dragging the lower right corner. So if I  
accidently move the widget window into the main qtcs window (which is  
very easy to do!) and then drag it out, I must manually resize the  
window. Combine this problem with the fact that I cannot minimize the  
main qtcs window (see below), this makes live performance very risky.

The widget window  must be clicked to gain focus for keystrokes even  
if it appears to float above the main qutecsound window. If the text  
edit pane is clicked during live performance, this pane gains focus  
and keystrokes are sent to the text edit window, even if the widget  
window is covering most of the text edit pane. During limited use, the  
widget window behaves as expected, however: keystrokes are correctly  
sent to it as long as the widget pane has focus (in previous version,  
keystrokes became captive to some other pane sometimes.)

The danger of losing keystrokes caused me to consider workarounds. So  
I considered during live performance: to "minimize" the qutecsound  
window, so that it cannot gain focus accidentally. Unfortunately this  
is not workable:

If the main qtcs window is minimized and focus is then given to  
another application, the widget window completely disappears. So it's  
not possible to return to qutecsound by clicking the widget window (it  
isn't available!) (However, at least the csd continues to play even  
though it's not visible.)

The important problem:  while the main qutecsound window is minimized,  
the widget window will not capture keystrokes - but it does capture  
mouse clicks.

Another problem regarding keystrokes: if I click a button or drag a  
scroll pad, the widget window will capture keystrokes afterwards,  
However, if I change a popup menu setting, the widget window will not  
capture keystrokes until I click the window. This problem existed in  
0.5.0 also.

Andres, congratulations on this clean-looking version. If there are  
any features you would like me to try out, I'll be happy to do so. I'm  
looking forward to working with the next version.

Best,
Lou Cohen






------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Qutecsound-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qutecsound-users
Reply | Threaded
Open this post in threaded view
|

Re: [Qutecsound-users] first use of qutecsound-f : comments

Andres Cabrera
Administrator
Hi Lou,

Thanks for the comments. Did you notice any improvement in terms of CPU usage?

On Sun, Jun 20, 2010 at 4:49 PM, Louis Cohen <[hidden email]> wrote:
> I tried editing the xml for a display widget, using Jedit. Even though
> I then loaded the modified file with QuteCsound, it seems that my edit
> was ignored. I changed the precision of a field from 3 to 1 (and also
> from 3 to zero.) But the displayed precision remained the same. Here
> is the text (after I edited it):

As you've found out, the format is still beyond the application...
This means that some things from the format are not yet used by the
application (but the definition of the format ensures that when this
information is there, the application will leave it there as it is).
Finishing implementing the new format is the priority for the next
release after this, but I wanted to get the ball rolling with a new
release as there have been many additions.
Some of the big changes from the new widget format are more
possibilities for text widgets (font sizes, border radius and width),
and controller ranges.
Also please try out and report on the preset system.

BTW Did fonts change size noticeably for your file?

> The controller widget has a slightly different behavior in this
> version compared to last version. It seems to behave more like the
> corresponding widget in MacCsound - a click, without dragging, moves
> the controller to new coordinates (as it does with MacCsound). In QTCS
> 0.5.0 it was necessary to click AND drag in order to change the
> coordinates of the cursor.
>

I hadn't realized this, but I think it's fine like this for now. The
format allows changing the behavior of mouse control for widgets, to
allow relative movement, but this hasn't been implemented...

> The widget window remains as before, not a true window, therefore must
> be manually sized by dragging the lower right corner. So if I
> accidently move the widget window into the main qtcs window (which is
> very easy to do!) and then drag it out, I must manually resize the
> window. Combine this problem with the fact that I cannot minimize the
> main qtcs window (see below), this makes live performance very risky.
>

What I do when this happens is not drag it out again, but double click
on the bar or use the "maximize" button of the widget panel and the
panel will take its previous size. But this is a great incovenience,
which I have in the list. It involves allowing the panel to be a
proper window instead of a dock widget, but this requires quite a bit
of work.

> The widget window  must be clicked to gain focus for keystrokes even
> if it appears to float above the main qutecsound window. If the text
> edit pane is clicked during live performance, this pane gains focus
> and keystrokes are sent to the text edit window, even if the widget
> window is covering most of the text edit pane. During limited use, the
> widget window behaves as expected, however: keystrokes are correctly
> sent to it as long as the widget pane has focus (in previous version,
> keystrokes became captive to some other pane sometimes.)
>

Yes, the widget panel is an always on top widget, so it can be on top
even if it doesn't have focus. There's nothing much that can be done
here... But I'm glad to hear that the behavior has improved.

> The danger of losing keystrokes caused me to consider workarounds. So
> I considered during live performance: to "minimize" the qutecsound
> window, so that it cannot gain focus accidentally. Unfortunately this
> is not workable:
>
> If the main qtcs window is minimized and focus is then given to
> another application, the widget window completely disappears. So it's
> not possible to return to qutecsound by clicking the widget window (it
> isn't available!) (However, at least the csd continues to play even
> though it's not visible.)
>

This is all a consequence of the widget panel being a dock widget.

> The important problem:  while the main qutecsound window is minimized,
> the widget window will not capture keystrokes - but it does capture
> mouse clicks.
>

What do you mean exactly by "capture mouse clicks"?

> Another problem regarding keystrokes: if I click a button or drag a
> scroll pad, the widget window will capture keystrokes afterwards,
> However, if I change a popup menu setting, the widget window will not
> capture keystrokes until I click the window. This problem existed in
> 0.5.0 also.
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Qutecsound-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qutecsound-users