qutecsound-users — Mailing list for user questions regarding QuteCsound

Re: [Qutecsound-users] nabble

[menno <nab...@ya...>]

and if you and me can read this then everything works :)

greetings
Menno
-- 
View this message in context: http://qutecsound-users.829572.n3.nabble.com/Re-Qutecsound-users-nabble-tp829592p831152.html
Sent from the QuteCsound Users mailing list archive at Nabble.com.

Re: [Qutecsound-users] Disable realtime input

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

Hi Carlos,

Yes, you are right, I've changed this for -i. -o will always be used if an
rt module is specified.

Cheers,
Andrés
-- 
View this message in context: http://qutecsound-users.829572.n3.nabble.com/Re-Qutecsound-users-Disable-realtime-input-tp829604p829616.html
Sent from the QuteCsound Users mailing list archive at Nabble.com.

Re: [Qutecsound-users] Disable realtime input

[Carlos P. <car...@gm...>]

> if (_configlists.rtAudioNames[rtAudioModule] != "none") {
>
> Would this be enough for your needs? Or why is it you want to specify
> a audio module, and have no "-i" flag?

Yes, for example:

-+rtaudio=alsa -odac

with no input.

Regards
--
Carlos

Re: [Qutecsound-users] nabble

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

Hi Menno,

I've set up a copy of the QuteCsound mailing list here:

http://qutecsound-users.829572.n3.nabble.com/

A test message from Nabble should soon make this list...

Cheers,
Andrés


On Wed, May 19, 2010 at 8:47 AM, menno <nab...@ya...> wrote:
> Hi Andres,
>
> some time ago i posted something to the Qutecsound users mailing list and you answered the question, but i did not notice until just now. The traffic of the qut...@li... is quite low so it takes weeks for a digest to get into my mailbox. Also the mailing list from Sourceforge is read-only, even after logging in.
> Would you consider, as QuteCsound, becoming a part of Nabble ( http://old.nabble.com/Csound-f480.html ) so that one can (re)act much quicker?
> Or, how is there a way i was not aware of?
>
> greetings
>
> Menno
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>



-- 


Andrés

[Qutecsound-users] Test from Nabble

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

Please Ignore...
-- 
View this message in context: http://qutecsound-users.829572.n3.nabble.com/Test-from-Nabble-tp829589p829589.html
Sent from the QuteCsound Users mailing list archive at Nabble.com.

Re: [Qutecsound-users] Disable realtime input

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

Hi Carlos,

This is done to assist beginners, which may be baffled when they have
no realtime output, and it will take them a long time to figure out
they need to put dac there. The current mechanism will not create an
"-i" flag if you select "none" as your rt audio module, since the line
you quote is within this conditinal:

if (_configlists.rtAudioNames[rtAudioModule] != "none") {

Would this be enough for your needs? Or why is it you want to specify
a audio module, and have no "-i" flag?

Cheers,
Andrés

On Wed, May 19, 2010 at 4:57 PM, Carlos Pita <car...@gm...> wrote:
> Hi,
>
> it would be nice if there were some way to disable realtime input. Currently:
>
>      list << "-i" + (rtInputDevice == "" ? "adc":rtInputDevice);
>
> So no matter which is the value of rtInputDevice, "-i" will be passed
> as a cli option to the csound instance.
>
> Maybe "" (= none in the configuration dialog) should be regarded as no
> input at all.
>
> Regards
> --
> Carlos
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>



-- 


Andrés

[Qutecsound-users] Disable realtime input

[Carlos P. <car...@gm...>]

Hi,

it would be nice if there were some way to disable realtime input. Currently:

      list << "-i" + (rtInputDevice == "" ? "adc":rtInputDevice);

So no matter which is the value of rtInputDevice, "-i" will be passed
as a cli option to the csound instance.

Maybe "" (= none in the configuration dialog) should be regarded as no
input at all.

Regards
--
Carlos

[Qutecsound-users] nabble

[menno <nab...@ya...>]

Hi Andres,

some time ago i posted something to the Qutecsound users mailing list and you answered the question, but i did not notice until just now. The traffic of the qut...@li... is quite low so it takes weeks for a digest to get into my mailbox. Also the mailing list from Sourceforge is read-only, even after logging in.
Would you consider, as QuteCsound, becoming a part of Nabble ( http://old.nabble.com/Csound-f480.html ) so that one can (re)act much quicker?
Or, how is there a way i was not aware of?

greetings

Menno


      

Re: [Qutecsound-users] Some issues with 0.5.0

[Felipe S. <fsa...@gm...>]

Nice!

Thanks for your work.

On Mon, May 10, 2010 at 11:59, Andres Cabrera <man...@gm...> wrote:
> Hi,
>
> I've now added this as well. The completion will not pop up if an
> opcode has been already used in the line and if there is a '='
> character. There are actually some functions like int which could be
> used in these cases, but the number of false entries that will pop up
> I think justifies disabling the menu in these cases.
>
> Cheers,
> Andrés
>
> On Sat, May 8, 2010 at 7:13 PM, Felipe Sateler <fsa...@gm...> wrote:
>> On Sat, May 8, 2010 at 03:53, Andres Cabrera <man...@gm...> wrote:
>>> Hola Felipe,
>>
>> Hola
>>
>>>
>>> On Thu, May 6, 2010 at 8:22 PM, Felipe Sateler <fsa...@gm...> wrote:
>>>> Hi all. I have a few issues to report, unfortunately :p.
>>>>
>>>
>>> As long as it's not horrible crashing causing whole system meltdown
>>> which damages the harddisk and the screen, I'm happy... =)
>>>
>>>> The autocompletion system is cool. However, it has some problems, as
>>>> it triggers in unneeded scenarios. For example, if I'm writing a named
>>>> instrument called printsomething, qutecsound will offer to
>>>> autocomplete the print opcode.
>>>
>>> OK, now it doesn't pop up when "instr" or "opcode" text is before in
>>> the current line. Any more scenarios that you can think of?
>>
>> I think so. If I understand csound correctly, opcodes can only occur
>> within instrument or UDO context, so they can only happen in the orc
>> (instr 0 allows opcodes).
>> Therefore, opcode autocompletion should not happen in the score.
>> Also, opcodes cannot happen in assignment context (asign = oscili
>> 1,1,1 is wrong, right?). And finally, comments (which is not really
>> wrong syntax, but maybe not really heplful).
>>
>> So, opcode autocompletion should be enabled only when all these
>> conditions apply:
>> 1. In instr/opcode context (only in the orc section)
>> 2. No operators have been written in this line (+ - = etc).
>> 3. Not in a comment
>> 4. No keyword is before the cursor (I can't nest opcodes).
>>
>>>> <more issues>
>>> Done.
>>>
>> <snip>
>>> Fixed.
>>
>> Cool :).
>>
>>
>>>> On another front, the output console prints red output for errors.
>>>> Good. But if I have harmless errors,it puts the whole screen in red.
>>>> For example, if my environment doesn't have RAWWAVE_PATH defined, then
>>>> the stk opcodes will print:
>>>>
>>>> Error: define environment variable RAWWAVE_PATH
>>>> (points to rawwaves directory) to use STK opcodes.
>>>>
>>>>
>>>> And then on the whole output will be red, even though csound is
>>>> running perfectly because my csd doesn't have stk opcodes in it.
>>>>
>>>> And really finally: I think the Shift+F1 shortcut should not redirect
>>>> to the index page if something was not found. It should just be there
>>>> and somehow notify the user (status bar?).
>>>>
>>>
>>> I've filed theses two in the tracker, to look at them later:
>>> https://sourceforge.net/tracker/?group_id=227265
>>>
>>> Thanks for the feedback.
>>
>> Thanks for the application ;).
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Qutecsound-users mailing list
>> Qut...@li...
>> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>>
>
>
>
> --
>
>
> Andrés
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>



-- 

Saludos,
Felipe Sateler

Re: [Qutecsound-users] Some issues with 0.5.0

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

Hi,

I've now added this as well. The completion will not pop up if an
opcode has been already used in the line and if there is a '='
character. There are actually some functions like int which could be
used in these cases, but the number of false entries that will pop up
I think justifies disabling the menu in these cases.

Cheers,
Andrés

On Sat, May 8, 2010 at 7:13 PM, Felipe Sateler <fsa...@gm...> wrote:
> On Sat, May 8, 2010 at 03:53, Andres Cabrera <man...@gm...> wrote:
>> Hola Felipe,
>
> Hola
>
>>
>> On Thu, May 6, 2010 at 8:22 PM, Felipe Sateler <fsa...@gm...> wrote:
>>> Hi all. I have a few issues to report, unfortunately :p.
>>>
>>
>> As long as it's not horrible crashing causing whole system meltdown
>> which damages the harddisk and the screen, I'm happy... =)
>>
>>> The autocompletion system is cool. However, it has some problems, as
>>> it triggers in unneeded scenarios. For example, if I'm writing a named
>>> instrument called printsomething, qutecsound will offer to
>>> autocomplete the print opcode.
>>
>> OK, now it doesn't pop up when "instr" or "opcode" text is before in
>> the current line. Any more scenarios that you can think of?
>
> I think so. If I understand csound correctly, opcodes can only occur
> within instrument or UDO context, so they can only happen in the orc
> (instr 0 allows opcodes).
> Therefore, opcode autocompletion should not happen in the score.
> Also, opcodes cannot happen in assignment context (asign = oscili
> 1,1,1 is wrong, right?). And finally, comments (which is not really
> wrong syntax, but maybe not really heplful).
>
> So, opcode autocompletion should be enabled only when all these
> conditions apply:
> 1. In instr/opcode context (only in the orc section)
> 2. No operators have been written in this line (+ - = etc).
> 3. Not in a comment
> 4. No keyword is before the cursor (I can't nest opcodes).
>
>>> <more issues>
>> Done.
>>
> <snip>
>> Fixed.
>
> Cool :).
>
>
>>> On another front, the output console prints red output for errors.
>>> Good. But if I have harmless errors,it puts the whole screen in red.
>>> For example, if my environment doesn't have RAWWAVE_PATH defined, then
>>> the stk opcodes will print:
>>>
>>> Error: define environment variable RAWWAVE_PATH
>>> (points to rawwaves directory) to use STK opcodes.
>>>
>>>
>>> And then on the whole output will be red, even though csound is
>>> running perfectly because my csd doesn't have stk opcodes in it.
>>>
>>> And really finally: I think the Shift+F1 shortcut should not redirect
>>> to the index page if something was not found. It should just be there
>>> and somehow notify the user (status bar?).
>>>
>>
>> I've filed theses two in the tracker, to look at them later:
>> https://sourceforge.net/tracker/?group_id=227265
>>
>> Thanks for the feedback.
>
> Thanks for the application ;).
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>



-- 


Andrés

Re: [Qutecsound-users] Ubuntu and QuteCsound

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

Hi Menno,

Yes, if you are using svn, you now need to go to the base directory,
not src/ and run qmake there.
(Bear in mind that svn right now is quite experimental (and somewhat
buggy) as it implements the new widget format, so you will be a bit of
a guinea pig, but I'd appreciate feedback)

Let us know if you have any problems still.

Cheers,
Andrés

On Sat, May 8, 2010 at 7:35 PM, menno <nab...@ya...> wrote:
> Hi,
> i have UbuntuStudio10.04. In the repo there is QuteCsound 0.4.3 so would like to have the latest version.
> I have build before on 9.10 but it seems things have changed a little.
> When i follow my own instructions from http://www.csounds.com/node/1380 i have a problem with qmake.
>
> menno@ubuntu:~/qutecsound/trunk/qutecsound/src$ qmake
> Usage: qmake [mode] [options] [files]
>
> QMake has two modes, one mode for generating project files based on
> some heuristics, and the other for generating makefiles. Normally you
> shouldn't need to specify a mode, as makefile generation is the default
> mode for qmake, but you may use this to test qmake on an existing project
>
> Mode:
>  -project       Put qmake into project file generation mode
>                 In this mode qmake interprets files as files to
>                 be built,
>                 defaults to *.c; *.ui; *.y; *.l; *.ts; *.xlf; *.qrc; *.h; *.hpp; *.hh; *.hxx; *.H; *.cpp; *.cc; *.cxx; *.C
>                 Note: The created .pro file probably will
>                 need to be edited. For example add the QT variable to
>                 specify what modules are required.
>  -makefile      Put qmake into makefile generation mode (default)
>                 In this mode qmake interprets files as project files to
>                 be processed, if skipped qmake will try to find a project
>                 file in your current working directory
>
> Warnings Options:
>  -Wnone         Turn off all warnings
>  -Wall          Turn on all warnings
>  -Wparser       Turn on parser warnings
>  -Wlogic        Turn on logic warnings
>
> Options:
>   * You can place any variable assignment in options and it will be     *
>   * processed as if it was in [files]. These assignments will be parsed *
>   * before [files].                                                     *
>  -o file        Write output to file
>  -unix          Run in unix mode
>  -win32         Run in win32 mode
>  -macx          Run in Mac OS X mode
>  -d             Increase debug level
>  -t templ       Overrides TEMPLATE as templ
>  -tp prefix     Overrides TEMPLATE so that prefix is prefixed into the value
>  -help          This help
>  -v             Version information
>  -after         All variable assignments after this will be
>                 parsed after [files]
>  -norecursive   Don't do a recursive search
>  -recursive     Do a recursive search
>  -set <prop> <value> Set persistent property
>  -query <prop>  Query persistent property. Show all if <prop> is empty.
>  -cache file    Use file as cache           [makefile mode only]
>  -spec spec     Use spec as QMAKESPEC       [makefile mode only]
>  -nocache       Don't use a cache file      [makefile mode only]
>  -nodepend      Don't generate dependencies [makefile mode only]
>  -nomoc         Don't generate moc targets  [makefile mode only]
>  -nopwd         Don't look for files in pwd [project mode only]
>
>
> also trying with qmake "CONFIG += build64" or qmake -makefile "CONFIG += build64" gives the same result.
> Any suggestions?
>
> greetings
> Menno
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>



-- 


Andrés

[Qutecsound-users] Ubuntu and QuteCsound

[menno <nab...@ya...>]

Hi,
i have UbuntuStudio10.04. In the repo there is QuteCsound 0.4.3 so would like to have the latest version.
I have build before on 9.10 but it seems things have changed a little.
When i follow my own instructions from http://www.csounds.com/node/1380 i have a problem with qmake. 

menno@ubuntu:~/qutecsound/trunk/qutecsound/src$ qmake
Usage: qmake [mode] [options] [files]

QMake has two modes, one mode for generating project files based on
some heuristics, and the other for generating makefiles. Normally you
shouldn't need to specify a mode, as makefile generation is the default
mode for qmake, but you may use this to test qmake on an existing project

Mode:
  -project       Put qmake into project file generation mode
                 In this mode qmake interprets files as files to
                 be built,
                 defaults to *.c; *.ui; *.y; *.l; *.ts; *.xlf; *.qrc; *.h; *.hpp; *.hh; *.hxx; *.H; *.cpp; *.cc; *.cxx; *.C
                 Note: The created .pro file probably will 
                 need to be edited. For example add the QT variable to 
                 specify what modules are required.
  -makefile      Put qmake into makefile generation mode (default)
                 In this mode qmake interprets files as project files to
                 be processed, if skipped qmake will try to find a project
                 file in your current working directory

Warnings Options:
  -Wnone         Turn off all warnings
  -Wall          Turn on all warnings
  -Wparser       Turn on parser warnings
  -Wlogic        Turn on logic warnings

Options:
   * You can place any variable assignment in options and it will be     *
   * processed as if it was in [files]. These assignments will be parsed *
   * before [files].                                                     *
  -o file        Write output to file
  -unix          Run in unix mode
  -win32         Run in win32 mode
  -macx          Run in Mac OS X mode
  -d             Increase debug level
  -t templ       Overrides TEMPLATE as templ
  -tp prefix     Overrides TEMPLATE so that prefix is prefixed into the value
  -help          This help
  -v             Version information
  -after         All variable assignments after this will be
                 parsed after [files]
  -norecursive   Don't do a recursive search
  -recursive     Do a recursive search
  -set <prop> <value> Set persistent property
  -query <prop>  Query persistent property. Show all if <prop> is empty.
  -cache file    Use file as cache           [makefile mode only]
  -spec spec     Use spec as QMAKESPEC       [makefile mode only]
  -nocache       Don't use a cache file      [makefile mode only]
  -nodepend      Don't generate dependencies [makefile mode only]
  -nomoc         Don't generate moc targets  [makefile mode only]
  -nopwd         Don't look for files in pwd [project mode only]


also trying with qmake "CONFIG += build64" or qmake -makefile "CONFIG += build64" gives the same result.
Any suggestions?

greetings
Menno




      

Re: [Qutecsound-users] Some issues with 0.5.0

[Felipe S. <fsa...@gm...>]

On Sat, May 8, 2010 at 03:53, Andres Cabrera <man...@gm...> wrote:
> Hola Felipe,

Hola

>
> On Thu, May 6, 2010 at 8:22 PM, Felipe Sateler <fsa...@gm...> wrote:
>> Hi all. I have a few issues to report, unfortunately :p.
>>
>
> As long as it's not horrible crashing causing whole system meltdown
> which damages the harddisk and the screen, I'm happy... =)
>
>> The autocompletion system is cool. However, it has some problems, as
>> it triggers in unneeded scenarios. For example, if I'm writing a named
>> instrument called printsomething, qutecsound will offer to
>> autocomplete the print opcode.
>
> OK, now it doesn't pop up when "instr" or "opcode" text is before in
> the current line. Any more scenarios that you can think of?

I think so. If I understand csound correctly, opcodes can only occur
within instrument or UDO context, so they can only happen in the orc
(instr 0 allows opcodes).
Therefore, opcode autocompletion should not happen in the score.
Also, opcodes cannot happen in assignment context (asign = oscili
1,1,1 is wrong, right?). And finally, comments (which is not really
wrong syntax, but maybe not really heplful).

So, opcode autocompletion should be enabled only when all these
conditions apply:
1. In instr/opcode context (only in the orc section)
2. No operators have been written in this line (+ - = etc).
3. Not in a comment
4. No keyword is before the cursor (I can't nest opcodes).

>> <more issues>
> Done.
>
<snip>
> Fixed.

Cool :).


>> On another front, the output console prints red output for errors.
>> Good. But if I have harmless errors,it puts the whole screen in red.
>> For example, if my environment doesn't have RAWWAVE_PATH defined, then
>> the stk opcodes will print:
>>
>> Error: define environment variable RAWWAVE_PATH
>> (points to rawwaves directory) to use STK opcodes.
>>
>>
>> And then on the whole output will be red, even though csound is
>> running perfectly because my csd doesn't have stk opcodes in it.
>>
>> And really finally: I think the Shift+F1 shortcut should not redirect
>> to the index page if something was not found. It should just be there
>> and somehow notify the user (status bar?).
>>
>
> I've filed theses two in the tracker, to look at them later:
> https://sourceforge.net/tracker/?group_id=227265
>
> Thanks for the feedback.

Thanks for the application ;).

-- 

Saludos,
Felipe Sateler

Re: [Qutecsound-users] Some issues with 0.5.0

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

Hola Felipe,

On Thu, May 6, 2010 at 8:22 PM, Felipe Sateler <fsa...@gm...> wrote:
> Hi all. I have a few issues to report, unfortunately :p.
>

As long as it's not horrible crashing causing whole system meltdown
which damages the harddisk and the screen, I'm happy... =)

> The autocompletion system is cool. However, it has some problems, as
> it triggers in unneeded scenarios. For example, if I'm writing a named
> instrument called printsomething, qutecsound will offer to
> autocomplete the print opcode.

OK, now it doesn't pop up when "instr" or "opcode" text is before in
the current line. Any more scenarios that you can think of?

Also, it will always autocomplete the
> full signature, so that doing this:
>
> aout osci<select autocompletion for oscil here>
>
> Will turn out to be:
> aout kres oscil kamp, kcps, ifn [, iphs]
>

Done.

> Finally, different signatures of the same opcode don't seem to work
> (eg, the kres and ares oscil autocompletions both autocomplete to the
> kres version).
>

Fixed.

> On another front, the output console prints red output for errors.
> Good. But if I have harmless errors,it puts the whole screen in red.
> For example, if my environment doesn't have RAWWAVE_PATH defined, then
> the stk opcodes will print:
>
> Error: define environment variable RAWWAVE_PATH
> (points to rawwaves directory) to use STK opcodes.
>
>
> And then on the whole output will be red, even though csound is
> running perfectly because my csd doesn't have stk opcodes in it.
>
> And really finally: I think the Shift+F1 shortcut should not redirect
> to the index page if something was not found. It should just be there
> and somehow notify the user (status bar?).
>

I've filed theses two in the tracker, to look at them later:
https://sourceforge.net/tracker/?group_id=227265

Thanks for the feedback.

Cheers,
Andrés

[Qutecsound-users] Python Print Statements Not in Console

[Jim A. <mid...@sb...>]

In trying out the ultra-basic Python code in issue 6 of the Csound 
Journal (a very good article written by Andres), I find that the Python 
print statements are not causing any output in the QuteCsound output 
console pane.

If I click Run In Terminal, the print statements show up. So QuteCsound 
is suppressing them.

Is there an option to override this behavior? Or is it a bug?

--JA

Re: [Qutecsound-users] Fwd: Qutecsound-users Digest, Vol 18, Issue 5 (latency)

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

Hi Lou,

On Fri, Apr 23, 2010 at 6:20 PM, Louis Cohen <do...@jo...> wrote:
> I'm sure I can work around the latency issue, now that I understand
> it. I was updating a widget at the end of one instrument's k-cycle,
> and expecting that the new value of the widget would control that same
> instrument's behavior during its next k-cycle. This worked well with
> MacCsound so I never thought much about any other way to handle this.

Thanks for the information. If MacCsound could do it, it means there
should be a way for QuteCsound to do it as well. I'll make a note to
look at this, and see if it can be done without any performance
penalty.

Cheers,
Andrés

[Qutecsound-users] Fwd: Qutecsound-users Digest, Vol 18, Issue 5 (latency)

[Louis C. <do...@jo...>]

Andres,

Thanks for this explanation.  I turned off "run as a separate thread"  
and got the same result -- the widget's update did not happen instantly.

I'm sure I can work around the latency issue, now that I understand  
it. I was updating a widget at the end of one instrument's k-cycle,  
and expecting that the new value of the widget would control that same  
instrument's behavior during its next k-cycle. This worked well with  
MacCsound so I never thought much about any other way to handle this.

I suspect, but I cannot prove, that sometime between an "outvalue" of  
a non-zero value, and a subsequent "invalue", the widget contains a  
zero value or some indeterminate value that gets reported as a zero. I  
may never be able to confirm this as I will be changing my processing  
to avoid the latency problem, so I won't be investigating the earlier  
design any longer.

I'm pretty sure it will be easy to simply set a variable instead of  
depending on the widget to update so quickly.

Andre, the bug I mentioned in the uploaded version of my improviser is  
probably caused by this latency problem. If you play around with the  
improviser's "Bong/Bang/Bing/Boing" section you may encounter the bug.  
As far as I can tell, all the other sections of the improviser work as  
I had intended. I'll be working on a fix in the next few days.

-Lou


Begin forwarded message:

>
> Message: 5
> Date: Fri, 23 Apr 2010 10:36:43 -0400
> From: Louis Cohen <lou...@jo...>
> Subject: [Qutecsound-users] Widget latency
> To: qut...@li...
> Message-ID: <968...@jo...>
> Content-Type: text/plain; charset="us-ascii"
>
> I've been trying to track down a bug in a rather large csd file
> lately. I'm not sure that the following is the key to my problem, but
> it does seem to be part of the trouble:
>
> It seems that there is a perceptible delay from the time that I load a
> widget with a value and when that the value may then be retrieved. In
> the attached csd file, which is the default qutecsound "Untitled" file
> plus a few extra lines of mine, I have this sequence:
>
> outvalue "test",20
> ktemp invalue "test"
> printk 1,ktemp
>
> "test" is the channel name for a scrollnumber widget. I would expect
> that when I print ktemp I would see a "20" but this is not exactly
> what happens. Here's the output:
>
> new alloc for instr 2:
> i 2 time 0.00290: 0.00000
> i 2 time 1.00136: 20.00000
> i 2 time 2.00272: 20.00000
> i 2 time 3.00118: 20.00000
> i 2 time 4.00254: 20.00000
> i 2 time 5.00100: 20.00000
> i 2 time 6.00236: 20.00000
>
> Apparently it takes some time before the outvalue opcode delivers the
> value 20 and the invalue opcode is able to see it. The environment is
> csound 5.10, Mac Pro, 2.66 GHz quad core Intel processor, qutecsound
> 0.5.0.
>
> I'm looking for ideas about how to deal with this latency in a csd
> file that uses more than 50 scrollnumber widgets plus many other
> widgets. Any thoughts?
>
> best,
> Lou Cohen
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: testlatency.csd
> Type: application/octet-stream
> Size: 2146 bytes
> Desc: not available
> -------------- next part --------------
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 23 Apr 2010 17:06:04 +0100
> From: Andres Cabrera <man...@gm...>
> Subject: Re: [Qutecsound-users] Widget latency
> To: qut...@li...
> Message-ID:
> 	<n2z...@ma...>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Lou,
>
> This is actually a bit of a connundrum... This is due to the fact that
> the widgets are running in a separate thread to Csound. This is
> efficient, because Csound won't have to wait for widgets to redraw, so
> there will be significantly less dropouts. However, since they are on
> different threads, in effect it's as if they are different
> applications, so the mechanism to communicate data between them relies
> on an intermediate buffer, which holds the data until it is passed to
> the receiver (this works in both directions). In practice, this
> produces the latency you describe, as you are querying the widget
> before the data has actually gotten to it. The data should be there
> shortly after.
> Unchecking "Run Csound in a separate thread" will not help either, as
> (if I rememeber correctly) the architecture is thread oriented, so you
> will see the same behavior (running a large set of widgets in the same
> thread as Csound is also bound to produce a lot of dropouts...).
> So what this means is that you can't count on widgets as a
> synchronized data storage mechanism.
> Maybe if you tell us what you're trying to do exactly, we can think of
> another way to do it...
>
> Cheers,
> Andr?s

Re: [Qutecsound-users] Widget latency

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

Hi Lou,

This is actually a bit of a connundrum... This is due to the fact that
the widgets are running in a separate thread to Csound. This is
efficient, because Csound won't have to wait for widgets to redraw, so
there will be significantly less dropouts. However, since they are on
different threads, in effect it's as if they are different
applications, so the mechanism to communicate data between them relies
on an intermediate buffer, which holds the data until it is passed to
the receiver (this works in both directions). In practice, this
produces the latency you describe, as you are querying the widget
before the data has actually gotten to it. The data should be there
shortly after.
Unchecking "Run Csound in a separate thread" will not help either, as
(if I rememeber correctly) the architecture is thread oriented, so you
will see the same behavior (running a large set of widgets in the same
thread as Csound is also bound to produce a lot of dropouts...).
So what this means is that you can't count on widgets as a
synchronized data storage mechanism.
Maybe if you tell us what you're trying to do exactly, we can think of
another way to do it...

Cheers,
Andrés


On Fri, Apr 23, 2010 at 3:36 PM, Louis Cohen <lou...@jo...> wrote:
> I've been trying to track down a bug in a rather large csd file lately. I'm
> not sure that the following is the key to my problem, but it does seem to be
> part of the trouble:
>
> It seems that there is a perceptible delay from the time that I load a
> widget with a value and when that the value may then be retrieved. In the
> attached csd file, which is the default qutecsound "Untitled" file plus a
> few extra lines of mine, I have this sequence:
>
> outvalue "test",20
> ktemp invalue "test"
> printk 1,ktemp
>
> "test" is the channel name for a scrollnumber widget. I would expect that
> when I print ktemp I would see a "20" but this is not exactly what happens.
> Here's the output:
>
> new alloc for instr 2:
> i 2 time 0.00290: 0.00000
> i 2 time 1.00136: 20.00000
> i 2 time 2.00272: 20.00000
> i 2 time 3.00118: 20.00000
> i 2 time 4.00254: 20.00000
> i 2 time 5.00100: 20.00000
> i 2 time 6.00236: 20.00000
>
> Apparently it takes some time before the outvalue opcode delivers the value
> 20 and the invalue opcode is able to see it. The environment is csound 5.10,
> Mac Pro, 2.66 GHz quad core Intel processor, qutecsound 0.5.0.
>
> I'm looking for ideas about how to deal with this latency in a csd file that
> uses more than 50 scrollnumber widgets plus many other widgets. Any
> thoughts?
>
> best,
> Lou Cohen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>
>



-- 


Andrés

[Qutecsound-users] Widget latency

[Louis C. <lou...@jo...>]

I've been trying to track down a bug in a rather large csd file  
lately. I'm not sure that the following is the key to my problem, but  
it does seem to be part of the trouble:

It seems that there is a perceptible delay from the time that I load a  
widget with a value and when that the value may then be retrieved. In  
the attached csd file, which is the default qutecsound "Untitled" file  
plus a few extra lines of mine, I have this sequence:

outvalue "test",20
ktemp invalue "test"
printk 1,ktemp

"test" is the channel name for a scrollnumber widget. I would expect  
that when I print ktemp I would see a "20" but this is not exactly  
what happens. Here's the output:

new alloc for instr 2:
i 2 time 0.00290: 0.00000
i 2 time 1.00136: 20.00000
i 2 time 2.00272: 20.00000
i 2 time 3.00118: 20.00000
i 2 time 4.00254: 20.00000
i 2 time 5.00100: 20.00000
i 2 time 6.00236: 20.00000

Apparently it takes some time before the outvalue opcode delivers the  
value 20 and the invalue opcode is able to see it. The environment is  
csound 5.10, Mac Pro, 2.66 GHz quad core Intel processor, qutecsound  
0.5.0.

I'm looking for ideas about how to deal with this latency in a csd  
file that uses more than 50 scrollnumber widgets plus many other  
widgets. Any thoughts?

best,
Lou Cohen

Re: [Qutecsound-users] csound error message?

[joachim h. <jh...@jo...>]

It's a question of the "full duplex mode", as Victor explained in
http://old.nabble.com/pvsbufread%2C-ksmps-and-ghosts-over-p3-to23684045.html#a23707140

I personally made the best experiences with ksmps*4 = -b and -b*4 = - 
B, for instance
ksmps = 16, -b = 64, -B = 256 (or 32/128/512, or more if there are  
dropouts).

	joachim


Am 20.04.2010 um 17:51 schrieb Andres Cabrera:

> Hi,
>
> If it causes no sound crackles, and performance is good you can forget
> about it...
> You can get rid of it by making sure -B is a multiple of ksmps. (or
> maybe it's -b? I'm not sure...)
>
> Cheers,
> Andrés
>
> On Tue, Apr 20, 2010 at 4:17 PM, Louis Cohen <do...@jo...> wrote:
>> I get the warning message near the end of the text below when I run  
>> my csd
>> file under qutecsound. What setting should I change to eliminate the
>> message? Or should I just forget about it?
>> best,
>> Lou Cohen
>>
>>
>> audio buffered in 1024 sample-frame blocks
>> reading 8192-byte blks of shorts from adc (RAW)
>> PortAudio V19-devel
>> PortAudio: available input devices:
>> 0: Built-in Microphone
>> 1: Built-in Input
>> 2: MOTU 828mk2
>> PortAudio: selected input device 'MOTU 828mk2'
>> PortAudio: available output devices:
>> 0: Built-in Output
>> 1: MOTU 828mk2
>> PortAudio: selected output device 'MOTU 828mk2'
>> WARNING: buffer size should be an integer multiple of ksmps in full- 
>> duplex
>> mode
>> writing 8192-byte blks of shorts to dac
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Qutecsound-users mailing list
>> Qut...@li...
>> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>>
>>
>
>
>
> -- 
>
>
> Andrés
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users

Re: [Qutecsound-users] csound error message?

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

Hi,

If it causes no sound crackles, and performance is good you can forget
about it...
You can get rid of it by making sure -B is a multiple of ksmps. (or
maybe it's -b? I'm not sure...)

Cheers,
Andrés

On Tue, Apr 20, 2010 at 4:17 PM, Louis Cohen <do...@jo...> wrote:
> I get the warning message near the end of the text below when I run my csd
> file under qutecsound. What setting should I change to eliminate the
> message? Or should I just forget about it?
> best,
> Lou Cohen
>
>
> audio buffered in 1024 sample-frame blocks
> reading 8192-byte blks of shorts from adc (RAW)
> PortAudio V19-devel
> PortAudio: available input devices:
> 0: Built-in Microphone
> 1: Built-in Input
> 2: MOTU 828mk2
> PortAudio: selected input device 'MOTU 828mk2'
> PortAudio: available output devices:
> 0: Built-in Output
> 1: MOTU 828mk2
> PortAudio: selected output device 'MOTU 828mk2'
> WARNING: buffer size should be an integer multiple of ksmps in full-duplex
> mode
> writing 8192-byte blks of shorts to dac
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>
>



-- 


Andrés

[Qutecsound-users] csound error message?

[Louis C. <do...@jo...>]

I get the warning message near the end of the text below when I run my  
csd file under qutecsound. What setting should I change to eliminate  
the message? Or should I just forget about it?

best,
Lou Cohen


>
> audio buffered in 1024 sample-frame blocks
> reading 8192-byte blks of shorts from adc (RAW)
> PortAudio V19-devel
> PortAudio: available input devices:
> 0: Built-in Microphone
> 1: Built-in Input
> 2: MOTU 828mk2
> PortAudio: selected input device 'MOTU 828mk2'
> PortAudio: available output devices:
> 0: Built-in Output
> 1: MOTU 828mk2
> PortAudio: selected output device 'MOTU 828mk2'
> WARNING: buffer size should be an integer multiple of ksmps in full- 
> duplex mode
> writing 8192-byte blks of shorts to dac

Re: [Qutecsound-users] Csound 5.12 and QuteCsound 0.5.0...

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

Hi,

Apparently the package for Debian works for Ubuntu as well, so it's no biggie.

Thanks.
Andrés

On Thu, Apr 15, 2010 at 6:15 PM, Felipe Sateler <fsa...@gm...> wrote:
> Unfortunately, it was just brought to my attention that the ubuntu
> feature freeze was started today :(. This means that they won't make
> it to lucid.
>
> On Thu, Apr 15, 2010 at 13:00, Andres Cabrera <man...@gm...> wrote:
>> Nice!! Thanks, I hope it trickles down to Ubuntu soon... (or maybe I
>> should just move back to Debian...)
>>
>> Cheers,
>> Andrés
>>
>> On Thu, Apr 15, 2010 at 3:02 PM, Felipe Sateler <fsa...@gm...> wrote:
>>> are now in debian unstable. Sorry for the delay, and enjoy.
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Qutecsound-users mailing list
>>> Qut...@li...
>>> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>>>
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Qutecsound-users mailing list
>> Qut...@li...
>> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>>
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>



-- 


Andrés

[Qutecsound-users] New widget format in svn

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

Hi all,

I'm using this list as the dev list ocasionally, so if you're a user,
you can ignore this message...

I just wanted to let people who build from source know that I've
merged the code to use the new widget format. The main visible changes
are that you can now set the font size for text in widgets as a number
and that you can now store presets in the csd file.

I'd appriacte if any early testers can have a look at this and provide
some feedback.

Cheers,
Andrés

Re: [Qutecsound-users] Csound 5.12 and QuteCsound 0.5.0...

[Felipe S. <fsa...@gm...>]

Unfortunately, it was just brought to my attention that the ubuntu
feature freeze was started today :(. This means that they won't make
it to lucid.

On Thu, Apr 15, 2010 at 13:00, Andres Cabrera <man...@gm...> wrote:
> Nice!! Thanks, I hope it trickles down to Ubuntu soon... (or maybe I
> should just move back to Debian...)
>
> Cheers,
> Andrés
>
> On Thu, Apr 15, 2010 at 3:02 PM, Felipe Sateler <fsa...@gm...> wrote:
>> are now in debian unstable. Sorry for the delay, and enjoy.
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Qutecsound-users mailing list
>> Qut...@li...
>> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>>
>
>
>
> --
>
>
> Andrés
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Qutecsound-users mailing list
> Qut...@li...
> https://lists.sourceforge.net/lists/listinfo/qutecsound-users
>



-- 

Saludos,
Felipe Sateler