Thread: [Qutecsound-users] first use of qutecsound-f : comments
Brought to you by:
mantaraya36
From: Louis C. <do...@jo...> - 2010-06-20 15:49:32
|
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 |
From: Andres C. <man...@gm...> - 2010-06-20 16:51:55
|
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 <do...@jo...> 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. > |