Hi All,

I came across this lovely video interview with Barry Vercoe:

http://video.mit.edu/watch/barry-l-vercoe-oral-history-interview-no-2-april-24-2012-12014/

I haven't watched the entire video yet, but the parts I enjoyed the
parts I've seen so far. I thought others here might find it
interesting.

steven

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks for sharing Steven!

On 25 May 2015 at 19:43, Steven Yi  wrote:
> Hi All,
>
> I came across this lovely video interview with Barry Vercoe:
>
> http://video.mit.edu/watch/barry-l-vercoe-oral-history-interview-no-2-april-24-2012-12014/
>
> I haven't watched the entire video yet, but the parts I enjoyed the
> parts I've seen so far. I thought others here might find it
> interesting.
>
> steven
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

On 05/25/2015 02:43 PM, Steven Yi wrote:
> Hi All,
>
> I came across this lovely video interview with Barry Vercoe:
>
>
> ...

Thanks a lot, Steven, it's a wonderful interview.

Btw, I don't think it's mentioned during the video, but Christopher 
Ariza is the author of the AthenaCL system.

Best,

dp


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks for pointing this out Steven, it was very interesting.

It brings to mind a question that occurs to me from time to time... In 
the interview, Barry talks about having his own version of Csound that 
he works with. That idea is intriguing because, though I greatly 
appreciate the fantastic bells and whistles provided by Csound 6, the 
implementation of arrays comes to mind, the main reason I use it is 
because it runs much faster than Csound 5. Otherwise, Csound 5 had all 
of the tools I require as a composer. So the question is... has any 
thought been put into making a "stripped down" version of Csound that 
has a focus more upon efficiency than upon additional features? Maybe 
there would not be a performance gain achieved by reducing the 
features... I am not qualified to know that but it seems possible. If 
this stripped down version of Csound were constrained to the features 
of, for example, Csound 5, while maintaining the efficiency of Csound 6, 
could there be a performance gain?

Perhaps this has been addressed in the past and I have missed it... but 
it is an interesting question.

Thanks to all,

Michael





On 5/25/15 2:43 PM, Steven Yi wrote:
> Hi All,
>
> I came across this lovely video interview with Barry Vercoe:
>
> http://video.mit.edu/watch/barry-l-vercoe-oral-history-interview-no-2-april-24-2012-12014/
>
> I haven't watched the entire video yet, but the parts I enjoyed the
> parts I've seen so far. I thought others here might find it
> interesting.
>
> steven
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>          https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>


------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I have a good experience working with GPUs and Csound, and my general observation is that, unless the
process is massively parallel, it will not be faster than most modern CPUs. Certain things can be really impressive,
for instance, using my laptop’s basic gpu, I was able to run zero-latency multi-partitioned convolution with
impulse responses of up to 4 minutes in realtime with no dropouts.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 27 May 2015, at 16:48, Michael Gogins  wrote:
> 
> Thanks, I agree.
> 
> I don't think we'll see big improvements in Csound runtime speed until more people are actually trying to use multi-threaded rendering, and we find any problems there and clean them up. But if that happens, I think we should see some real improvement. 
> 
> Another potential way of getting real improvement is to compile at least parts of Csound for the GPU. But this is different on different platforms, so far.
> 
> Best,
> Mike
> 
> 
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> On Wed, May 27, 2015 at 11:29 AM, Steven Yi  wrote:
> Hi Michael,
> 
> It's an interesting question.  I can't imagine anything in CS6 (or CS7) that has really impacted the run-time performance of Csound. Most of the additions and changes have come at compile time (for Csound's compiler, not when compiling Csound itself :)), with the exception of sample-accurate code.  Even then, the cost is fairly negligible when amortized with block-based processing. 
> 
> Probably some of the gains we've seen going from CS5 to CS6 have been in the compilation phase, due to changes in choices of data structures during compilation, as well as reimplemented opcode and variable lookup, and further caching of lookups. 
> 
> For performance, I imagine whatever is gained from this point out won't be from stripping out features.  Since CS5's new parser, there has been a compiler pass for optimizing the TREE that hasn't been fully implemented.  There are standard techniques for optimization that we could benefit from (i.e., constant folding, dead code elimination, etc.).   Some of the newer features could probably be optimized in and of themselves, but even then, if you don't use the newer features, then it won't really affect your performance. 
> 
> That said, we'd really need benchmarks and profiling information to really find out if there's been anything introduced that has affected performance. The last time I ran Csound using XCode's Instruments, I didn't really see anything that stuck out as being unexpected or as an opportunity for speedup, but maybe things have changed or I missed something.  
> 
> Moving ahead, it'd be great if we had more eyes looking at both single-thread and multi-threaded performance in Csound.  I imagine for single-thread, there won't be massive gains found, but small one will add up.  For multi-thread, it's really the place where we'd potentially get the most gains, but it's a hard problem when applied to audio, IMO.  
> 
> That's my two cents at least. :)
> 
> steven
> 
> On Wed, May 27, 2015 at 1:44 AM, Michael Rhoades  wrote:
> Thanks for pointing this out Steven, it was very interesting.
> 
> It brings to mind a question that occurs to me from time to time... In
> the interview, Barry talks about having his own version of Csound that
> he works with. That idea is intriguing because, though I greatly
> appreciate the fantastic bells and whistles provided by Csound 6, the
> implementation of arrays comes to mind, the main reason I use it is
> because it runs much faster than Csound 5. Otherwise, Csound 5 had all
> of the tools I require as a composer. So the question is... has any
> thought been put into making a "stripped down" version of Csound that
> has a focus more upon efficiency than upon additional features? Maybe
> there would not be a performance gain achieved by reducing the
> features... I am not qualified to know that but it seems possible. If
> this stripped down version of Csound were constrained to the features
> of, for example, Csound 5, while maintaining the efficiency of Csound 6,
> could there be a performance gain?
> 
> Perhaps this has been addressed in the past and I have missed it... but
> it is an interesting question.
> 
> Thanks to all,
> 
> Michael
> 
> 
> 
> 
> 
> On 5/25/15 2:43 PM, Steven Yi wrote:
> > Hi All,
> >
> > I came across this lovely video interview with Barry Vercoe:
> >
> > http://video.mit.edu/watch/barry-l-vercoe-oral-history-interview-no-2-april-24-2012-12014/
> >
> > I haven't watched the entire video yet, but the parts I enjoyed the
> > parts I've seen so far. I thought others here might find it
> > interesting.
> >
> > steven
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Csound-users mailing list
> > Csound-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-users
> > Send bugs reports to
> >          https://github.com/csound/csound/issues
> > Discussions of bugs and features can be posted here
> >
> >
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Michael,

It's an interesting question.  I can't imagine anything in CS6 (or CS7) that has really impacted the run-time performance of Csound. Most of the additions and changes have come at compile time (for Csound's compiler, not when compiling Csound itself :)), with the exception of sample-accurate code.  Even then, the cost is fairly negligible when amortized with block-based processing. 

Probably some of the gains we've seen going from CS5 to CS6 have been in the compilation phase, due to changes in choices of data structures during compilation, as well as reimplemented opcode and variable lookup, and further caching of lookups. 

For performance, I imagine whatever is gained from this point out won't be from stripping out features.  Since CS5's new parser, there has been a compiler pass for optimizing the TREE that hasn't been fully implemented.  There are standard techniques for optimization that we could benefit from (i.e., constant folding, dead code elimination, etc.).   Some of the newer features could probably be optimized in and of themselves, but even then, if you don't use the newer features, then it won't really affect your performance. 

That said, we'd really need benchmarks and profiling information to really find out if there's been anything introduced that has affected performance. The last time I ran Csound using XCode's Instruments, I didn't really see anything that stuck out as being unexpected or as an opportunity for speedup, but maybe things have changed or I missed something.  

Moving ahead, it'd be great if we had more eyes looking at both single-thread and multi-threaded performance in Csound.  I imagine for single-thread, there won't be massive gains found, but small one will add up.  For multi-thread, it's really the place where we'd potentially get the most gains, but it's a hard problem when applied to audio, IMO.  

That's my two cents at least. :)

steven

On Wed, May 27, 2015 at 1:44 AM, Michael Rhoades <mrhoades@perceptionfactory.com> wrote:

Thanks for pointing this out Steven, it was very interesting.

It brings to mind a question that occurs to me from time to time... In
the interview, Barry talks about having his own version of Csound that
he works with. That idea is intriguing because, though I greatly
appreciate the fantastic bells and whistles provided by Csound 6, the
implementation of arrays comes to mind, the main reason I use it is
because it runs much faster than Csound 5. Otherwise, Csound 5 had all
of the tools I require as a composer. So the question is... has any
thought been put into making a "stripped down" version of Csound that
has a focus more upon efficiency than upon additional features? Maybe
there would not be a performance gain achieved by reducing the
features... I am not qualified to know that but it seems possible. If
this stripped down version of Csound were constrained to the features
of, for example, Csound 5, while maintaining the efficiency of Csound 6,
could there be a performance gain?

Perhaps this has been addressed in the past and I have missed it... but
it is an interesting question.

Thanks to all,

Michael

btw use of --sample-accurate can give better efficiency!  When I first 
tested it on "Trappe..." I was confused that it was faster, until I 
realised that it was stopping earlier/starting later in a kblock so 
actually doing less.   However there is a small cost in checking/setting 
the smalled loops at perf time

Also... I sspect Barry is using floats always while the current system 
uses doubles internally for filters etc, even in float builds.  Against 
that many modern processors are optimised for doubles.  I think the small 
loss is worth the quality but you (whoever you are) may not agree.

I may seek a student to look at this.

==John ff

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Michael,

Have you tried Csound's multicore implementation?  By default, Csound runs single threaded.  If you use the --num-threads=x flag, it will use the multicore implemntation.  You could try with --num-threads=8 and see what happens.  Note, when ksmps is small (i.e., ksmps=1), the performance will likely degrade.  But with higher ksmps you should see a bit faster renders.  (With higher ksmps, using --sample-accurate will get more precise timing).  

steven

On Wed, May 27, 2015 at 12:01 PM, Michael Rhoades <mrhoades@perceptionfactory.com> wrote:

Hi Steven, John, Michael et al,

I appreciate everyone taking time to explain things. It is very interesting and it is quite amazing what all of the developers are accomplishing. I simply render sound files, not concerned with real time, and the increase in rendering time from CS5 to CS6 was considerable...  which of course makes the compositional process more transparent to the creative flow and so is extremely welcomed.

One thing I notice on my Win 8.1 machine is that the CPU cores are not fully utilized during a render. For instance, when I am rendering I see that all 8 cores, of my i7 processor, are being utilized but only at 16%. I recently built a rendering farm, 4 servers, for MAYA and when I am using them the cores are all being used at 100%, which significantly increases frame rendering rates. I notice too that Sonar uses 100% of all of the cores as well...  I realize I have little idea what is behind making it happen, but at least on a Win 8.1 OS it would seem that some performance gain could be had in that area.

Michael

On 5/27/15 11:29 AM, Steven Yi wrote:

Hi Michael,

It's an interesting question.  I can't imagine anything in CS6 (or CS7) that has really impacted the run-time performance of Csound. Most of the additions and changes have come at compile time (for Csound's compiler, not when compiling Csound itself :)), with the exception of sample-accurate code.  Even then, the cost is fairly negligible when amortized with block-based processing. 

Probably some of the gains we've seen going from CS5 to CS6 have been in the compilation phase, due to changes in choices of data structures during compilation, as well as reimplemented opcode and variable lookup, and further caching of lookups. 

For performance, I imagine whatever is gained from this point out won't be from stripping out features.  Since CS5's new parser, there has been a compiler pass for optimizing the TREE that hasn't been fully implemented.  There are standard techniques for optimization that we could benefit from (i.e., constant folding, dead code elimination, etc.).   Some of the newer features could probably be optimized in and of themselves, but even then, if you don't use the newer features, then it won't really affect your performance. 

That said, we'd really need benchmarks and profiling information to really find out if there's been anything introduced that has affected performance. The last time I ran Csound using XCode's Instruments, I didn't really see anything that stuck out as being unexpected or as an opportunity for speedup, but maybe things have changed or I missed something.  

Moving ahead, it'd be great if we had more eyes looking at both single-thread and multi-threaded performance in Csound.  I imagine for single-thread, there won't be massive gains found, but small one will add up.  For multi-thread, it's really the place where we'd potentially get the most gains, but it's a hard problem when applied to audio, IMO.  

That's my two cents at least. :)

steven

On Wed, May 27, 2015 at 1:44 AM, Michael Rhoades <mrhoades@perceptionfactory.com> wrote:

Thanks for pointing this out Steven, it was very interesting.

It brings to mind a question that occurs to me from time to time... In
the interview, Barry talks about having his own version of Csound that
he works with. That idea is intriguing because, though I greatly
appreciate the fantastic bells and whistles provided by Csound 6, the
implementation of arrays comes to mind, the main reason I use it is
because it runs much faster than Csound 5. Otherwise, Csound 5 had all
of the tools I require as a composer. So the question is... has any
thought been put into making a "stripped down" version of Csound that
has a focus more upon efficiency than upon additional features? Maybe
there would not be a performance gain achieved by reducing the
features... I am not qualified to know that but it seems possible. If
this stripped down version of Csound were constrained to the features
of, for example, Csound 5, while maintaining the efficiency of Csound 6,
could there be a performance gain?

Perhaps this has been addressed in the past and I have missed it... but
it is an interesting question.

Thanks to all,

Michael

------------------------------------------------------------------------------

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

------------------------------------------------------------------------------

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Steven,

No I had not tried it before but I did just now.

The syntax --num-threads=8 raised an error, no known flag. But when I used a -j 8 flag it worked. It is utilizing around 90% of all 8 cores and seems a bit faster using a ksmps=10. I do not have time right now to compare the time difference.

How do I use the --sample-accurate flag? I may need to upgrade to a newer version of CS6... I am on 6.02 maybe that is the difference in the flags?

Michael



On 5/27/15 12:26 PM, Steven Yi wrote:

Hi Michael,

Have you tried Csound's multicore implementation?  By default, Csound runs single threaded.  If you use the --num-threads=x flag, it will use the multicore implemntation.  You could try with --num-threads=8 and see what happens.  Note, when ksmps is small (i.e., ksmps=1), the performance will likely degrade.  But with higher ksmps you should see a bit faster renders.  (With higher ksmps, using --sample-accurate will get more precise timing).  

steven

On Wed, May 27, 2015 at 12:01 PM, Michael Rhoades <mrhoades@perceptionfactory.com> wrote:

Hi Steven, John, Michael et al,

I appreciate everyone taking time to explain things. It is very interesting and it is quite amazing what all of the developers are accomplishing. I simply render sound files, not concerned with real time, and the increase in rendering time from CS5 to CS6 was considerable...  which of course makes the compositional process more transparent to the creative flow and so is extremely welcomed.

One thing I notice on my Win 8.1 machine is that the CPU cores are not fully utilized during a render. For instance, when I am rendering I see that all 8 cores, of my i7 processor, are being utilized but only at 16%. I recently built a rendering farm, 4 servers, for MAYA and when I am using them the cores are all being used at 100%, which significantly increases frame rendering rates. I notice too that Sonar uses 100% of all of the cores as well...  I realize I have little idea what is behind making it happen, but at least on a Win 8.1 OS it would seem that some performance gain could be had in that area.

Michael

On 5/27/15 11:29 AM, Steven Yi wrote:

Hi Michael,

It's an interesting question.  I can't imagine anything in CS6 (or CS7) that has really impacted the run-time performance of Csound. Most of the additions and changes have come at compile time (for Csound's compiler, not when compiling Csound itself :)), with the exception of sample-accurate code.  Even then, the cost is fairly negligible when amortized with block-based processing. 

Probably some of the gains we've seen going from CS5 to CS6 have been in the compilation phase, due to changes in choices of data structures during compilation, as well as reimplemented opcode and variable lookup, and further caching of lookups. 

For performance, I imagine whatever is gained from this point out won't be from stripping out features.  Since CS5's new parser, there has been a compiler pass for optimizing the TREE that hasn't been fully implemented.  There are standard techniques for optimization that we could benefit from (i.e., constant folding, dead code elimination, etc.).   Some of the newer features could probably be optimized in and of themselves, but even then, if you don't use the newer features, then it won't really affect your performance. 

That said, we'd really need benchmarks and profiling information to really find out if there's been anything introduced that has affected performance. The last time I ran Csound using XCode's Instruments, I didn't really see anything that stuck out as being unexpected or as an opportunity for speedup, but maybe things have changed or I missed something.  

Moving ahead, it'd be great if we had more eyes looking at both single-thread and multi-threaded performance in Csound.  I imagine for single-thread, there won't be massive gains found, but small one will add up.  For multi-thread, it's really the place where we'd potentially get the most gains, but it's a hard problem when applied to audio, IMO.  

That's my two cents at least. :)

steven

On Wed, May 27, 2015 at 1:44 AM, Michael Rhoades <mrhoades@perceptionfactory.com> wrote:

Thanks for pointing this out Steven, it was very interesting.

It brings to mind a question that occurs to me from time to time... In
the interview, Barry talks about having his own version of Csound that
he works with. That idea is intriguing because, though I greatly
appreciate the fantastic bells and whistles provided by Csound 6, the
implementation of arrays comes to mind, the main reason I use it is
because it runs much faster than Csound 5. Otherwise, Csound 5 had all
of the tools I require as a composer. So the question is... has any
thought been put into making a "stripped down" version of Csound that
has a focus more upon efficiency than upon additional features? Maybe
there would not be a performance gain achieved by reducing the
features... I am not qualified to know that but it seems possible. If
this stripped down version of Csound were constrained to the features
of, for example, Csound 5, while maintaining the efficiency of Csound 6,
could there be a performance gain?

Perhaps this has been addressed in the past and I have missed it... but
it is an interesting question.

Thanks to all,

Michael

------------------------------------------------------------------------------

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

------------------------------------------------------------------------------

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

------------------------------------------------------------------------------

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Excellent... this all sounds really good.

I just tried the --sample-accurate flag and that worked. It will take a 
bit of time to modify my code so that all of the envelopes are a rate... 
I use a lot of them. But will give it a try as time permits. Makes 
perfect sense.

Thanks tons!!



On 5/27/15 1:41 PM, Steven Yi wrote:
> Only thing to add from what Michael G and Victor said is to upgrade to 
> 6.05. I'm not sure everything that changed between 6.02 and now, but 
> overall it should be better for both CPU and memory.
>


------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Anders,

this got left unanswered. The code for partitioned and direct convolution opcodes using CUDA is in GIT (and it is
currently released for OSX). With these you can build a no-delay convolution by setting up the direct convolution
opcode to do the lead partition and the rest with the partitioned convolution opcode. You will need of course to
split the impulse response accordingly. I might have the CSD somewhere, I will look. Note that you should also be able to
do this with dconv and one of the normal partitioned convolution opcodes (but not with 4-minute-long IRs).

Regards
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 9 Jun 2015, at 09:55, Anders Genell  wrote:
> 
> Dear Dr Lazzarini!
> This tidbit had been baking my noodle now for a couple of weeks. Would it be presumptuous to ask for a (idiot-safe) write-up of how to do zero-latency multi-partitioned convolution using csound and (I suppose) cuda?
> For full Nirvana-like experience it would be combined with csLadspa, so that an extraordinary audio processing ladspa plugin could be running effortlessly on an ordinary machine?
> 
> 
> Regards,
> Anders
> 
> On Wed, May 27, 2015 at 6:00 PM, Victor Lazzarini  wrote:
> I have a good experience working with GPUs and Csound, and my general observation is that, unless the
> process is massively parallel, it will not be faster than most modern CPUs. Certain things can be really impressive,
> for instance, using my laptop’s basic gpu, I was able to run zero-latency multi-partitioned convolution with
> impulse responses of up to 4 minutes in realtime with no dropouts.
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
> 
> > On 27 May 2015, at 16:48, Michael Gogins  wrote:
> >
> > Thanks, I agree.
> >
> > I don't think we'll see big improvements in Csound runtime speed until more people are actually trying to use multi-threaded rendering, and we find any problems there and clean them up. But if that happens, I think we should see some real improvement.
> >
> > Another potential way of getting real improvement is to compile at least parts of Csound for the GPU. But this is different on different platforms, so far.
> >
> > Best,
> > Mike
> >
> >
> >
> >
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> > On Wed, May 27, 2015 at 11:29 AM, Steven Yi  wrote:
> > Hi Michael,
> >
> > It's an interesting question.  I can't imagine anything in CS6 (or CS7) that has really impacted the run-time performance of Csound. Most of the additions and changes have come at compile time (for Csound's compiler, not when compiling Csound itself :)), with the exception of sample-accurate code.  Even then, the cost is fairly negligible when amortized with block-based processing.
> >
> > Probably some of the gains we've seen going from CS5 to CS6 have been in the compilation phase, due to changes in choices of data structures during compilation, as well as reimplemented opcode and variable lookup, and further caching of lookups.
> >
> > For performance, I imagine whatever is gained from this point out won't be from stripping out features.  Since CS5's new parser, there has been a compiler pass for optimizing the TREE that hasn't been fully implemented.  There are standard techniques for optimization that we could benefit from (i.e., constant folding, dead code elimination, etc.).   Some of the newer features could probably be optimized in and of themselves, but even then, if you don't use the newer features, then it won't really affect your performance.
> >
> > That said, we'd really need benchmarks and profiling information to really find out if there's been anything introduced that has affected performance. The last time I ran Csound using XCode's Instruments, I didn't really see anything that stuck out as being unexpected or as an opportunity for speedup, but maybe things have changed or I missed something.
> >
> > Moving ahead, it'd be great if we had more eyes looking at both single-thread and multi-threaded performance in Csound.  I imagine for single-thread, there won't be massive gains found, but small one will add up.  For multi-thread, it's really the place where we'd potentially get the most gains, but it's a hard problem when applied to audio, IMO.
> >
> > That's my two cents at least. :)
> >
> > steven
> >
> > On Wed, May 27, 2015 at 1:44 AM, Michael Rhoades  wrote:
> > Thanks for pointing this out Steven, it was very interesting.
> >
> > It brings to mind a question that occurs to me from time to time... In
> > the interview, Barry talks about having his own version of Csound that
> > he works with. That idea is intriguing because, though I greatly
> > appreciate the fantastic bells and whistles provided by Csound 6, the
> > implementation of arrays comes to mind, the main reason I use it is
> > because it runs much faster than Csound 5. Otherwise, Csound 5 had all
> > of the tools I require as a composer. So the question is... has any
> > thought been put into making a "stripped down" version of Csound that
> > has a focus more upon efficiency than upon additional features? Maybe
> > there would not be a performance gain achieved by reducing the
> > features... I am not qualified to know that but it seems possible. If
> > this stripped down version of Csound were constrained to the features
> > of, for example, Csound 5, while maintaining the efficiency of Csound 6,
> > could there be a performance gain?
> >
> > Perhaps this has been addressed in the past and I have missed it... but
> > it is an interesting question.
> >
> > Thanks to all,
> >
> > Michael
> >
> >
> >
> >
> >
> > On 5/25/15 2:43 PM, Steven Yi wrote:
> > > Hi All,
> > >
> > > I came across this lovely video interview with Barry Vercoe:
> > >
> > > http://video.mit.edu/watch/barry-l-vercoe-oral-history-interview-no-2-april-24-2012-12014/
> > >
> > > I haven't watched the entire video yet, but the parts I enjoyed the
> > > parts I've seen so far. I thought others here might find it
> > > interesting.
> > >
> > > steven
> > >
> > > ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > _______________________________________________
> > > Csound-users mailing list
> > > Csound-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/csound-users
> > > Send bugs reports to
> > >          https://github.com/csound/csound/issues
> > > Discussions of bugs and features can be posted here
> > >
> > >
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Csound-users mailing list
> > Csound-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-users
> > Send bugs reports to
> >         https://github.com/csound/csound/issues
> > Discussions of bugs and features can be posted here
> >
> >
> > ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Csound-users mailing list
> > Csound-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-users
> > Send bugs reports to
> >         https://github.com/csound/csound/issues
> > Discussions of bugs and features can be posted here
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Csound-users mailing list
> > Csound-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-users
> > Send bugs reports to
> >        https://github.com/csound/csound/issues
> > Discussions of bugs and features can be posted here
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here