Hi everyone,

csound~ v1.1.0 is now available at:

http://www.davixology.com/csound~.html

csound~ is now compiled using the Max5 SDK, which means there is no Max4
version.
Also, I've dropped support for ppc mac.  As always, feedback and bug reports
are welcome.

Here is the changelog:

v1.1.0 

(** = backwards compatibility issue)
(*  = deprecation issue)

- Rewritten using C++, STL, and Boost for added robustness and lower
maintenance effort.

- Better cooperation with Max threading architecture (potential hangs
eliminated, now
  using spinlocks). 

- Uses Max5 attributes (there's a csound~ tab in the inspector window).

- Can specify Max objects in the orchestra. Format is "<~> ... " where
"..."
  is a Max script for creating an object.

- Messages printed to the Max window can now be traced back to a specific
csound~
  instance by double-clicking on a line in the Max window.

- Warnings are colored light orange in the Max window instead of red.

- Can save sequences as JSON or XML files (in addition to binary format).

- If @matchsr attribute is 1, csound~ will auto recompile Csound with
sample-rate
  overrides whenever host sample-rate does not equal Csound sample-rate. 
ksmps will
  be preserved.

- Fixed deadlock issues when using outlet data to trigger other csound~
functions.

- Fixed memory deallocation bug when running debug build of csound~.
   
- If csound~ is in bypass mode, sending "start" or "bang" to compile the
orchestra
  will not be followed by an automatic run of 1 k-cycle performance.

- If csound~ is in bypass mode, MIDI bytes are not queued.

- Non-editable attribute @nolatency tells you when csound~ is processing
audio
  without latency.

** No longer Max4 compatible. 

** rsidx output message format has changed to: "rsidx table# index value".
    
* @start is deprecated. Please use @autostart instead.

* @scale and "noscale" is deprecated. Audio is automatically scaled when
0dBFS
  levels don't match.

Hi Davis,

I don't use Max, but his called my attention:

On Thu, Sep 2, 2010 at 3:44 AM, dp51  wrote:
> - Uses Max5 attributes (there's a csound~ tab in the inspector window).
>
> - Can specify Max objects in the orchestra. Format is "<~> ... " where
> "..."
>  is a Max script for creating an object.
>

Can you give me more information about this, or where I can find some
documentation? It seems like things I want to do with QuteCsound, so I
would like to see how they are done in Max.

Cheers,
Andrés


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

There's a brief section in the pdf.  The manual is included in all installers
(including the manual installer). Also, there's an example patch and csd
that you can access from csound~.maxpat. 

At the moment, it's merely a way to create max objects from the csd file. I
may add further scripting capabilities in the future.

Davis

I'm afraid the max scripting capability is limited to object creation at the
moment. There are some companion objects that are created for named objects. 
These companion objects simply prepend "c name_of_object" to whatever comes
out the first outlet and forwards it to whatever is named "csound~" in your
patch.

Also, you can put <~> ...  anywhere. If you put them in the orchestra,
they should be in comment blocks.

Davis

Thanks that's interesting.

Cheers,
Andrés

On Thu, Sep 2, 2010 at 5:21 PM, dp51  wrote:
>
> I'm afraid the max scripting capability is limited to object creation at the
> moment. There are some companion objects that are created for named objects.
> These companion objects simply prepend "c name_of_object" to whatever comes
> out the first outlet and forwards it to whatever is named "csound~" in your
> patch.
>
> Also, you can put <~> ...  anywhere. If you put them in the orchestra,
> they should be in comment blocks.
>
> Davis
> --
> View this message in context: http://csound.1045644.n5.nabble.com/csound-v1-1-0-tp2800122p2800920.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



-- 


Andrés


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Amazing as usual!

Thanks for the new release.

Best,

Peiman

On 2 Sep 2010, at 04:44, dp51 wrote:

>
> Hi everyone,
>
> csound~ v1.1.0 is now available at:
>
> http://www.davixology.com/csound~.html
>
> csound~ is now compiled using the Max5 SDK, which means there is no  
> Max4
> version.
> Also, I've dropped support for ppc mac.  As always, feedback and bug  
> reports
> are welcome.
>
> Here is the changelog:
>
> v1.1.0
>
> (** = backwards compatibility issue)
> (*  = deprecation issue)
>
> - Rewritten using C++, STL, and Boost for added robustness and lower
> maintenance effort.
>
> - Better cooperation with Max threading architecture (potential hangs
> eliminated, now
>  using spinlocks).
>
> - Uses Max5 attributes (there's a csound~ tab in the inspector  
> window).
>
> - Can specify Max objects in the orchestra. Format is "<~> ... "  
> where
> "..."
>  is a Max script for creating an object.
>
> - Messages printed to the Max window can now be traced back to a  
> specific
> csound~
>  instance by double-clicking on a line in the Max window.
>
> - Warnings are colored light orange in the Max window instead of red.
>
> - Can save sequences as JSON or XML files (in addition to binary  
> format).
>
> - If @matchsr attribute is 1, csound~ will auto recompile Csound with
> sample-rate
>  overrides whenever host sample-rate does not equal Csound sample- 
> rate.
> ksmps will
>  be preserved.
>
> - Fixed deadlock issues when using outlet data to trigger other  
> csound~
> functions.
>
> - Fixed memory deallocation bug when running debug build of csound~.
>
> - If csound~ is in bypass mode, sending "start" or "bang" to compile  
> the
> orchestra
>  will not be followed by an automatic run of 1 k-cycle performance.
>
> - If csound~ is in bypass mode, MIDI bytes are not queued.
>
> - Non-editable attribute @nolatency tells you when csound~ is  
> processing
> audio
>  without latency.
>
> ** No longer Max4 compatible.
>
> ** rsidx output message format has changed to: "rsidx table# index  
> value".
>
> * @start is deprecated. Please use @autostart instead.
>
> * @scale and "noscale" is deprecated. Audio is automatically scaled  
> when
> 0dBFS
>  levels don't match.
> -- 
> View this message in context: http://csound.1045644.n5.nabble.com/csound-v1-1-0-tp2800122p2800122.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

One question.

Would it be possible to request a feature for the future releases?

It would be nice to have a message similar to wsidx but instead of  
writing at individual index values to be able to change the table  
values by interpolating between the values at given indexes in a list  
and filling in all the indexes in between. So for instance one could  
set the entire table to zero by sending [0 0 1024 0] or more complex  
[0 1 10 0 1024 1].

Cheers

Peiman



On 2 Sep 2010, at 04:44, dp51 wrote:

>
> Hi everyone,
>
> csound~ v1.1.0 is now available at:
>
> http://www.davixology.com/csound~.html
>
> csound~ is now compiled using the Max5 SDK, which means there is no  
> Max4
> version.
> Also, I've dropped support for ppc mac.  As always, feedback and bug  
> reports
> are welcome.
>
> Here is the changelog:
>
> v1.1.0
>
> (** = backwards compatibility issue)
> (*  = deprecation issue)
>
> - Rewritten using C++, STL, and Boost for added robustness and lower
> maintenance effort.
>
> - Better cooperation with Max threading architecture (potential hangs
> eliminated, now
>  using spinlocks).
>
> - Uses Max5 attributes (there's a csound~ tab in the inspector  
> window).
>
> - Can specify Max objects in the orchestra. Format is "<~> ... "  
> where
> "..."
>  is a Max script for creating an object.
>
> - Messages printed to the Max window can now be traced back to a  
> specific
> csound~
>  instance by double-clicking on a line in the Max window.
>
> - Warnings are colored light orange in the Max window instead of red.
>
> - Can save sequences as JSON or XML files (in addition to binary  
> format).
>
> - If @matchsr attribute is 1, csound~ will auto recompile Csound with
> sample-rate
>  overrides whenever host sample-rate does not equal Csound sample- 
> rate.
> ksmps will
>  be preserved.
>
> - Fixed deadlock issues when using outlet data to trigger other  
> csound~
> functions.
>
> - Fixed memory deallocation bug when running debug build of csound~.
>
> - If csound~ is in bypass mode, sending "start" or "bang" to compile  
> the
> orchestra
>  will not be followed by an automatic run of 1 k-cycle performance.
>
> - If csound~ is in bypass mode, MIDI bytes are not queued.
>
> - Non-editable attribute @nolatency tells you when csound~ is  
> processing
> audio
>  without latency.
>
> ** No longer Max4 compatible.
>
> ** rsidx output message format has changed to: "rsidx table# index  
> value".
>
> * @start is deprecated. Please use @autostart instead.
>
> * @scale and "noscale" is deprecated. Audio is automatically scaled  
> when
> 0dBFS
>  levels don't match.
> -- 
> View this message in context: http://csound.1045644.n5.nabble.com/csound-v1-1-0-tp2800122p2800122.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

BTW this is very nice. It means that users who don't have maxmsp can  
create sliders and GUI controllers from inside the csd and open the  
csd in a standalone max application with their scripted sliders.

Maybe a standalone app could be included in the next release of csound~.

P

On 2 Sep 2010, at 18:21, dp51 wrote:

>
> I'm afraid the max scripting capability is limited to object  
> creation at the
> moment. There are some companion objects that are created for named  
> objects.
> These companion objects simply prepend "c name_of_object" to  
> whatever comes
> out the first outlet and forwards it to whatever is named "csound~"  
> in your
> patch.
>
> Also, you can put <~> ...  anywhere. If you put them in the  
> orchestra,
> they should be in comment blocks.
>
> Davis
> -- 
> View this message in context: http://csound.1045644.n5.nabble.com/csound-v1-1-0-tp2800122p2800920.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

hi all,
            window displaying pthreadCG2.dll missing when trying to run 
qutecsound. someone please can send the file to this address 
(superpija2@yahoo.com) thanks in advance    Spija


      



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I'm going to update the installer very soon. In the meantime, you can
download the file from http://sourceware.org/pthreads-win32/.

Regards,
Mike

On Mon, Sep 6, 2010 at 10:35 AM, Super Pija  wrote:
> hi all,
>            window displaying pthreadCG2.dll missing when trying to run
> qutecsound. someone please can send the file to this address
> (superpija2@yahoo.com) thanks in advance    Spija
>
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Of course you can request features.  In fact, expanding wsidx to allow for
initialization
to fixed or interpolated values is not hard. I just have to decide on a
flexible implementation.
I recognize the advantage of an expanded wsidx. It would be easier than
using uzi/zl iter and
counter to send a bunch of messages).

I think what I'll do is emulate a small subset of the functionality provided
by the GEN functions.

DAvis

Huh. Scripting a runtime or app patch. You know, that never even occurred to
me. 

In the past few days, I've been thinking about how to expand the scripting
capability,
but the engineering side of me (i.e. the lazy one) wants to use the
thispatcher object.
What I mean is that thispatcher already implements all the scripting
cababilities you
could ever want. By parsing a csd for scripting statements that thispatcher
understands,
and then creating a temporary thispatcher object (via scripting, of course)
in order to
process scripting statements seems like the best way to go forward. 

As for the creation of an csound~ app, well... I'll get around to it
someday. It's a good
idea, but it's too broad at this point. I'm gonna have to come up with some
design goals
or some inspirational feature set.  

Davis

On 6 Sep 2010, at 19:37, dp51 wrote:

>
> Of course you can request features.  In fact, expanding wsidx to  
> allow for
> initialization
> to fixed or interpolated values is not hard. I just have to decide  
> on a
> flexible implementation.
> I recognize the advantage of an expanded wsidx. It would be easier  
> than
> using uzi/zl iter and
> counter to send a bunch of messages).
>
> I think what I'll do is emulate a small subset of the functionality  
> provided
> by the GEN functions.
>

Thanks, that's a very nice idea indeed :-)

Peiman

> DAvis
> -- 
> View this message in context: http://csound.1045644.n5.nabble.com/csound-v1-1-0-tp2800122p2805218.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Sounds great. One thing I noticed today was that using the command  
'parse tosub' to create the UI elements in a subpatcher doesn't work  
here. When moving the sliders inside the subpatcher I get this error  
'pattrforward: could not resolve requested object (csound~)' I think  
this is because pattrforward only knows about the objects in the  
current patcher. Maybe there is a workaround? I'm not very experienced  
at scripting in max.

Best,

Peiman


On 6 Sep 2010, at 20:12, dp51 wrote:

>
> Huh. Scripting a runtime or app patch. You know, that never even  
> occurred to
> me.
>
> In the past few days, I've been thinking about how to expand the  
> scripting
> capability,
> but the engineering side of me (i.e. the lazy one) wants to use the
> thispatcher object.
> What I mean is that thispatcher already implements all the scripting
> cababilities you
> could ever want. By parsing a csd for scripting statements that  
> thispatcher
> understands,
> and then creating a temporary thispatcher object (via scripting, of  
> course)
> in order to
> process scripting statements seems like the best way to go forward.
>
> As for the creation of an csound~ app, well... I'll get around to it
> someday. It's a good
> idea, but it's too broad at this point. I'm gonna have to come up  
> with some
> design goals
> or some inspirational feature set.
>
> Davis
> -- 
> View this message in context: http://csound.1045644.n5.nabble.com/csound-v1-1-0-tp2800122p2805245.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

That was intentional. The subpatch in which new objects are created was
intended
as a temporary workspace. Once you made changes in the subpatch, you would
then
move objects to the main patch (where csound~ resides).  That's why the
pattrforward
target is "csound~" rather than "parent::csound~". Unfortunately, there's no
way
to change this behavior at the moment (without modifying csound~ code).

On the bright side, I'm going to start expanding the scripting capabilities
in the coming
weeks. Stay tuned!

Davis