I'm thinking vaguely of attempting some sort of real-time interactive piece
that would involve both music and graphics. Glancing through the Csound
manual, I find no indication of support for real-time graphics output to the
computer screen. I'm not opposed to using Pd, but I'm more familiar with
Csound coding, so I need to ask:

Am I missing something obvious? Or is Csound still strictly for audio?

I'm not complaining -- I don't think it's a bad thing to concentrate on
audio! I'm just asking. Thanks.

--Jim Aikin

You can use Processing in conjunction with Csound, either through the
use of OSC or by integrating Csound within Processing using the host
API. Have a look at Jim Hearon's article about this in the Csound
Journal.

Rory.


On 11/05/2010, Jim Aikin  wrote:
>
> I'm thinking vaguely of attempting some sort of real-time interactive piece
> that would involve both music and graphics. Glancing through the Csound
> manual, I find no indication of support for real-time graphics output to the
> computer screen. I'm not opposed to using Pd, but I'm more familiar with
> Csound coding, so I need to ask:
>
> Am I missing something obvious? Or is Csound still strictly for audio?
>
> I'm not complaining -- I don't think it's a bad thing to concentrate on
> audio! I'm just asking. Thanks.
>
> --Jim Aikin
> --
> View this message in context:
> http://old.nabble.com/Graphics-Support-tp28520247p28520247.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"

Thanks for the tip, Rory. That article was way over my head, though ... and
would have been even if it hadn't been written strictly for Linux users.

One nice thing about Pd is that the graphics support is integrated. It
appears that one could, for example, use a single LFO both for video
processing and audio modulation without having to send messages flying back
and forth over OSC.

It also occurs to me to wonder how much of Csound's core audio code is
optimized for real-time processing. Csound has been around for a long time,
and my impression from years ago was that it wasn't very optimized, because
at the time it was created there was no need to think about real-time
output. But possibly that changed with version 5; as I said, it was years
ago that I ran into CPU issues with real-time Csound.

Another factor to consider is that I might want to hook up with a more
accomplished graphic artist as a co-conspirator. For someone who had little
or no background in programming, Pd would likely be more appealing than
Csound -- not actually any easier in practice, but more intuitively inviting
at first glance than a .csd file.

None of these comments is intended to disrespect Csound, which I truly love.
On the other side of the coin, I would hate to try to do complex sound
design in Pd, or write a score that required precise rhythms and notes that
had numerous parameters. But for the kind of project I'm contemplating, I
think Pd may be the way to go.

--JA


RoryWalsh wrote:
> 
> You can use Processing in conjunction with Csound, either through the
> use of OSC or by integrating Csound within Processing using the host
> API. Have a look at Jim Hearon's article about this in the Csound
> Journal.
> 
> Rory.
> 
> 
> On 11/05/2010, Jim Aikin  wrote:
>>
>> I'm thinking vaguely of attempting some sort of real-time interactive
>> piece
>> that would involve both music and graphics. Glancing through the Csound
>> manual, I find no indication of support for real-time graphics output to
>> the
>> computer screen. I'm not opposed to using Pd, but I'm more familiar with
>> Csound coding, so I need to ask:
>>
>> Am I missing something obvious? Or is Csound still strictly for audio?
>>
>> I'm not complaining -- I don't think it's a bad thing to concentrate on
>> audio! I'm just asking. Thanks.
>>
>> --Jim Aikin
>> --
>> View this message in context:
>> http://old.nabble.com/Graphics-Support-tp28520247p28520247.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"
> 
> 
> 

you can still run Csound with PD using csoundapi~

Victor
On 11 May 2010, at 15:59, Jim Aikin wrote:

>
> Thanks for the tip, Rory. That article was way over my head,  
> though ... and
> would have been even if it hadn't been written strictly for Linux  
> users.
>
> One nice thing about Pd is that the graphics support is integrated. It
> appears that one could, for example, use a single LFO both for video
> processing and audio modulation without having to send messages  
> flying back
> and forth over OSC.
>
> It also occurs to me to wonder how much of Csound's core audio code is
> optimized for real-time processing. Csound has been around for a  
> long time,
> and my impression from years ago was that it wasn't very optimized,  
> because
> at the time it was created there was no need to think about real-time
> output. But possibly that changed with version 5; as I said, it was  
> years
> ago that I ran into CPU issues with real-time Csound.
>
> Another factor to consider is that I might want to hook up with a more
> accomplished graphic artist as a co-conspirator. For someone who had  
> little
> or no background in programming, Pd would likely be more appealing  
> than
> Csound -- not actually any easier in practice, but more intuitively  
> inviting
> at first glance than a .csd file.
>
> None of these comments is intended to disrespect Csound, which I  
> truly love.
> On the other side of the coin, I would hate to try to do complex sound
> design in Pd, or write a score that required precise rhythms and  
> notes that
> had numerous parameters. But for the kind of project I'm  
> contemplating, I
> think Pd may be the way to go.
>
> --JA
>
>
> RoryWalsh wrote:
>>
>> You can use Processing in conjunction with Csound, either through the
>> use of OSC or by integrating Csound within Processing using the host
>> API. Have a look at Jim Hearon's article about this in the Csound
>> Journal.
>>
>> Rory.
>>
>>
>> On 11/05/2010, Jim Aikin  wrote:
>>>
>>> I'm thinking vaguely of attempting some sort of real-time  
>>> interactive
>>> piece
>>> that would involve both music and graphics. Glancing through the  
>>> Csound
>>> manual, I find no indication of support for real-time graphics  
>>> output to
>>> the
>>> computer screen. I'm not opposed to using Pd, but I'm more  
>>> familiar with
>>> Csound coding, so I need to ask:
>>>
>>> Am I missing something obvious? Or is Csound still strictly for  
>>> audio?
>>>
>>> I'm not complaining -- I don't think it's a bad thing to  
>>> concentrate on
>>> audio! I'm just asking. Thanks.
>>>
>>> --Jim Aikin
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Graphics-Support-tp28520247p28520247.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"
>>
>>
>>
>
> -- 
> View this message in context: http://old.nabble.com/Graphics-Support-tp28520247p28525259.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"

It's not at all true to say that Csound code was not optimized because
it was not originally oriented to live performance. When Csound was
created, in 1984, computers were far slower than they are today and
efficiency was a very high priority for Barry Vercoe and the other
early implementors of Csound. I also know that some portions of Csound
code were hand-optimized with considerable experimentation, e.g. the
digital oscillators do wrap-around using bit-masking instead of the
modulus operator because that was found to be faster (one big reason
for the power of 2 requirement for function table sizes). And Csound
is plain C code, which is be subject to considerable optimization by
all widely used contemporary compilers. Such optimizations include
vectorization and pipelining.

In light of this history, and also I have looked at a great deal of
Csound and other system's audio code, I think that Csound would be
competitive in terms of audio processing efficiency and speed,
compared with other open source software such as Pure Data or
SuperCollider.

That said, proprietary software synthesizers may take advantage of the
Intel C compiler (which may generate faster code than the gcc compiler
used to build Csound), or of the Intel performance libraries, which
offer additional optimizations.

Proprietary synthesizers that are not user-programmable may also gain
speed by statically linking all stages of sound synthesis, instead of
using dynamically linked lists of unit generators as all
user-programmable software synthesizers do. Compilers can perform
additional optimizations on large statically linked bodies of code.

Things are changing, however, parallel processing is happening. All
implementors of software synthesis systems are changing their designs
to take advantage of multi-core computers. This should end up
substantially increasing audio throughput. Currently Max/MSP already
has a form of concurrency. Csound has an "alpha" version of concurrent
processing. I believe SuperCollider either has, or soon will have,
some form of concurrency.

One of my personal priorities for Csound is to move the concurrent
version of Csound forward.

About doing visuals with Csound, my advice is to script your visuals
in some environment or language which does what you want. You could
use Visual Python, or maybe Blender, or perhaps some dynamic language
game engine. I would then use the Csound API to dispatch events from
the visualization code to Csound for audio rendering, and read audio
out of Csound's raw output buffers to write into the visualization
system's audio input.

Peter Brinkmann has done just this for his JReality mathematics
visualization system, using the Java interface to Csound. It wasn't
hard for him to do, but I think it would be even easier to do in
Python or Lua.

Regards,
Mike

On Tue, May 11, 2010 at 11:07 AM, Victor Lazzarini
 wrote:
> you can still run Csound with PD using csoundapi~
>
> Victor
> On 11 May 2010, at 15:59, Jim Aikin wrote:
>
>>
>> Thanks for the tip, Rory. That article was way over my head, though ...
>> and
>> would have been even if it hadn't been written strictly for Linux users.
>>
>> One nice thing about Pd is that the graphics support is integrated. It
>> appears that one could, for example, use a single LFO both for video
>> processing and audio modulation without having to send messages flying
>> back
>> and forth over OSC.
>>
>> It also occurs to me to wonder how much of Csound's core audio code is
>> optimized for real-time processing. Csound has been around for a long
>> time,
>> and my impression from years ago was that it wasn't very optimized,
>> because
>> at the time it was created there was no need to think about real-time
>> output. But possibly that changed with version 5; as I said, it was years
>> ago that I ran into CPU issues with real-time Csound.
>>
>> Another factor to consider is that I might want to hook up with a more
>> accomplished graphic artist as a co-conspirator. For someone who had
>> little
>> or no background in programming, Pd would likely be more appealing than
>> Csound -- not actually any easier in practice, but more intuitively
>> inviting
>> at first glance than a .csd file.
>>
>> None of these comments is intended to disrespect Csound, which I truly
>> love.
>> On the other side of the coin, I would hate to try to do complex sound
>> design in Pd, or write a score that required precise rhythms and notes
>> that
>> had numerous parameters. But for the kind of project I'm contemplating, I
>> think Pd may be the way to go.
>>
>> --JA
>>
>>
>> RoryWalsh wrote:
>>>
>>> You can use Processing in conjunction with Csound, either through the
>>> use of OSC or by integrating Csound within Processing using the host
>>> API. Have a look at Jim Hearon's article about this in the Csound
>>> Journal.
>>>
>>> Rory.
>>>
>>>
>>> On 11/05/2010, Jim Aikin  wrote:
>>>>
>>>> I'm thinking vaguely of attempting some sort of real-time interactive
>>>> piece
>>>> that would involve both music and graphics. Glancing through the Csound
>>>> manual, I find no indication of support for real-time graphics output to
>>>> the
>>>> computer screen. I'm not opposed to using Pd, but I'm more familiar with
>>>> Csound coding, so I need to ask:
>>>>
>>>> Am I missing something obvious? Or is Csound still strictly for audio?
>>>>
>>>> I'm not complaining -- I don't think it's a bad thing to concentrate on
>>>> audio! I'm just asking. Thanks.
>>>>
>>>> --Jim Aikin
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/Graphics-Support-tp28520247p28520247.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"
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Graphics-Support-tp28520247p28525259.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"
>
>



-- 
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"

On 11/05/2010 15:59, Jim Aikin wrote:
..
>
> It also occurs to me to wonder how much of Csound's core audio code is
> optimized for real-time processing.

Quite a lot, probably. It may not have been real-time all those years 
ago, but CPU cycles on relatively slow machines were just as much an 
issue. The table lookup code (requiring the power-of-two constraint) is 
the clearest example; by minimising conditional tests it achieves a 
remarkable level of  efficiency, and the simple expedient of enabling 
the user to select the processing granularity (ksmps) enables user to 
get as fast a turnaround as possible in development while retaining the 
option of a slower hifi rendering at the end. More modern (post-Vercoe, 
shall we say) opcodes may have been somewhat less concerned with raw 
clock cycles, but the core Csound certainly seemed to achieve a lot on 
an 8MHz Atari XT. Even what we can generously call its attempt at 
garbage collection probably played its part.

But then, with pvoc as the benchmark, it was bound to seem like that!

And it is worth remembering (with affection etc) that with remarkably 
little alteration it was ported (as XTCsound) to run in real time on the 
SHARC dsp (well, two of them). Still have one in a drawer here 
somewhere. That project may have slumped (?) for all sorts of reasons, 
but I don't think that speed was one of them. Csound is still the engine 
on the OLPC machine, where again cycles matter. And it may yet one day 
find a whole new career opportunity on the iPhone and iPad (etc).


Richard Dobson



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 forgot about AVSynthesis. I've used GEM quite a lot with Pd, it's a
nice environment, as too is Gridflow for Pd. More and more however I
find myself wanting to explore Processing. I've seen some really nice
interactive work done with it and it's trivial to hook it up to
Csound.

Rory.


On 11 May 2010 16:33, Brian Wong  wrote:
> Rory,
> I have not tried it yet myself because my video card is incompatible, but
> you might want to take a look at AVSynthesis. "AVSynthesis is a composition
> tool that combines the power of Csound and GLSL shaders in an easy to use
> User Interface. Sound synthesis and image transformations are intimately
> linked by the composition process to produce cinematic landscapes, evolving
> graphical abstractions..."
> http://avsynthesis.blogspot.com/
> If you do decide to try pd, be sure to install the optional "Gem" graphics
> package. I'm a beginner with pd, but pd with Gem appears to have fairly
> impressive video capabilities.
> BW
>
>> Date: Tue, 11 May 2010 10:32:54 +0100
>> From: rorywalsh@ear.ie
>> To: csound@lists.bath.ac.uk
>> Subject: [Csnd] Re: Graphics Support
>>
>> You can use Processing in conjunction with Csound, either through the
>> use of OSC or by integrating Csound within Processing using the host
>> API. Have a look at Jim Hearon's article about this in the Csound
>> Journal.
>>
>> Rory.
>>
>>
>> On 11/05/2010, Jim Aikin  wrote:
>> >
>> > I'm thinking vaguely of attempting some sort of real-time interactive
>> > piece
>> > that would involve both music and graphics. Glancing through the Csound
>> > manual, I find no indication of support for real-time graphics output to
>> > the
>> > computer screen. I'm not opposed to using Pd, but I'm more familiar with
>> > Csound coding, so I need to ask:
>> >
>> > Am I missing something obvious? Or is Csound still strictly for audio?
>> >
>> > I'm not complaining -- I don't think it's a bad thing to concentrate on
>> > audio! I'm just asking. Thanks.
>> >
>> > --Jim Aikin
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Graphics-Support-tp28520247p28520247.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"
>>
>
> ________________________________
> 30 days of prizes to be won with Hotmail. Enter here


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 posted a simple example which uses OSC rather than the Csound API.
you can find it here http://www.csounds.com/node/1368
Let me know if you've any problems, it only illustrates communication
from Processing to Csound, it's just as simple the other way around.

Rory.




On 11 May 2010 17:53, Brian Wong  wrote:
> Thanks Rory, I will check out "Processing", though I suspect our respective
> definitions of "trivial" vary somewhat. :)
> Brian
>
>> From: rorywalsh@ear.ie
>> Date: Tue, 11 May 2010 17:06:17 +0100
>> To: csound@lists.bath.ac.uk
>> Subject: [Csnd] Re: RE: Re: Graphics Support
>>
>> I forgot about AVSynthesis. I've used GEM quite a lot with Pd, it's a
>> nice environment, as too is Gridflow for Pd. More and more however I
>> find myself wanting to explore Processing. I've seen some really nice
>> interactive work done with it and it's trivial to hook it up to
>> Csound.
>>
>> Rory.
>>
>>
>> On 11 May 2010 16:33, Brian Wong  wrote:
>> > Rory,
>> > I have not tried it yet myself because my video card is incompatible,
>> > but
>> > you might want to take a look at AVSynthesis. "AVSynthesis is a
>> > composition
>> > tool that combines the power of Csound and GLSL shaders in an easy to
>> > use
>> > User Interface. Sound synthesis and image transformations are intimately
>> > linked by the composition process to produce cinematic landscapes,
>> > evolving
>> > graphical abstractions..."
>> > http://avsynthesis.blogspot.com/
>> > If you do decide to try pd, be sure to install the optional "Gem"
>> > graphics
>> > package. I'm a beginner with pd, but pd with Gem appears to have fairly
>> > impressive video capabilities.
>> > BW
>> >
>> >> Date: Tue, 11 May 2010 10:32:54 +0100
>> >> From: rorywalsh@ear.ie
>> >> To: csound@lists.bath.ac.uk
>> >> Subject: [Csnd] Re: Graphics Support
>> >>
>> >> You can use Processing in conjunction with Csound, either through the
>> >> use of OSC or by integrating Csound within Processing using the host
>> >> API. Have a look at Jim Hearon's article about this in the Csound
>> >> Journal.
>> >>
>> >> Rory.
>> >>
>> >>
>> >> On 11/05/2010, Jim Aikin  wrote:
>> >> >
>> >> > I'm thinking vaguely of attempting some sort of real-time interactive
>> >> > piece
>> >> > that would involve both music and graphics. Glancing through the
>> >> > Csound
>> >> > manual, I find no indication of support for real-time graphics output
>> >> > to
>> >> > the
>> >> > computer screen. I'm not opposed to using Pd, but I'm more familiar
>> >> > with
>> >> > Csound coding, so I need to ask:
>> >> >
>> >> > Am I missing something obvious? Or is Csound still strictly for
>> >> > audio?
>> >> >
>> >> > I'm not complaining -- I don't think it's a bad thing to concentrate
>> >> > on
>> >> > audio! I'm just asking. Thanks.
>> >> >
>> >> > --Jim Aikin
>> >> > --
>> >> > View this message in context:
>> >> > http://old.nabble.com/Graphics-Support-tp28520247p28520247.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"
>> >>
>> >
>> > ________________________________
>> > 30 days of prizes to be won with Hotmail. Enter here
>>
>>
>> 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"
>>
>
> ________________________________
> 30 days of prizes: Hotmail makes your day easier! Enter now


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 not sure who that question is addressed to but there are two ways,
one is with OSC which I illustrate in the previous post, and the other
is using the API from within Processing which Jim Hearon shows in his
Csound Journal article. A student of mine is currently looking at
making this process a whole lot easier but as it stands it should be
too tricky. I know that Jim's article focuses on Linux but it will
work for other platforms too.

Rory.


On 11 May 2010 18:16, Anthony Palomba  wrote:
> Just out of curiosity, how were you intending to hook Processing up to
> csound.
> I assume you would be using OSC. Yes?
>
>
> -ap
>
>
>
> On Tue, May 11, 2010 at 11:53 AM, Brian Wong 
> wrote:
>>
>> Thanks Rory, I will check out "Processing", though I suspect our
>> respective definitions of "trivial" vary somewhat. :)
>> Brian
>>
>> > From: rorywalsh@ear.ie
>> > Date: Tue, 11 May 2010 17:06:17 +0100
>> > To: csound@lists.bath.ac.uk
>> > Subject: [Csnd] Re: RE: Re: Graphics Support
>> >
>> > I forgot about AVSynthesis. I've used GEM quite a lot with Pd, it's a
>> > nice environment, as too is Gridflow for Pd. More and more however I
>> > find myself wanting to explore Processing. I've seen some really nice
>> > interactive work done with it and it's trivial to hook it up to
>> > Csound.
>> >
>> > Rory.
>> >
>> >
>> > On 11 May 2010 16:33, Brian Wong  wrote:
>> > > Rory,
>> > > I have not tried it yet myself because my video card is incompatible,
>> > > but
>> > > you might want to take a look at AVSynthesis. "AVSynthesis is a
>> > > composition
>> > > tool that combines the power of Csound and GLSL shaders in an easy to
>> > > use
>> > > User Interface. Sound synthesis and image transformations are
>> > > intimately
>> > > linked by the composition process to produce cinematic landscapes,
>> > > evolving
>> > > graphical abstractions..."
>> > > http://avsynthesis.blogspot.com/
>> > > If you do decide to try pd, be sure to install the optional "Gem"
>> > > graphics
>> > > package. I'm a beginner with pd, but pd with Gem appears to have
>> > > fairly
>> > > impressive video capabilities.
>> > > BW
>> > >
>> > >> Date: Tue, 11 May 2010 10:32:54 +0100
>> > >> From: rorywalsh@ear.ie
>> > >> To: csound@lists.bath.ac.uk
>> > >> Subject: [Csnd] Re: Graphics Support
>> > >>
>> > >> You can use Processing in conjunction with Csound, either through the
>> > >> use of OSC or by integrating Csound within Processing using the host
>> > >> API. Have a look at Jim Hearon's article about this in the Csound
>> > >> Journal.
>> > >>
>> > >> Rory.
>> > >>
>> > >>
>> > >> On 11/05/2010, Jim Aikin  wrote:
>> > >> >
>> > >> > I'm thinking vaguely of attempting some sort of real-time
>> > >> > interactive
>> > >> > piece
>> > >> > that would involve both music and graphics. Glancing through the
>> > >> > Csound
>> > >> > manual, I find no indication of support for real-time graphics
>> > >> > output to
>> > >> > the
>> > >> > computer screen. I'm not opposed to using Pd, but I'm more familiar
>> > >> > with
>> > >> > Csound coding, so I need to ask:
>> > >> >
>> > >> > Am I missing something obvious? Or is Csound still strictly for
>> > >> > audio?
>> > >> >
>> > >> > I'm not complaining -- I don't think it's a bad thing to
>> > >> > concentrate on
>> > >> > audio! I'm just asking. Thanks.
>> > >> >
>> > >> > --Jim Aikin
>> > >> > --
>> > >> > View this message in context:
>> > >> > http://old.nabble.com/Graphics-Support-tp28520247p28520247.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"
>> > >>
>> > >
>> > > ________________________________
>> > > 30 days of prizes to be won with Hotmail. Enter here
>> >
>> >
>> > 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"
>> >
>>
>> ________________________________
>> 30 days of prizes: Hotmail makes your day easier! Enter now
>


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"

In PD its not recommended to run graphic intensive patches together with 
audio. Its preferred to run separate PD instances to avoid clicks and 
let them communicate through OSC. For instance last friday I had an 
exhibition of an installation doing motion tracking, video replay in 3D 
environment for simple mapping and audio synthesis and had three PD 
instances running. Worked fine on a small EEE netbook but that approach 
takes away that benefit you mentioned to have all together in one patch.

Cheers,

Malte

Hi Malte, when you say three instance are you talking about three
instances running on one machine, or 3 instance on three separate
machines?

On 14 May 2010 14:03, Malte Steiner  wrote:
> In PD its not recommended to run graphic intensive patches together with
> audio. Its preferred to run separate PD instances to avoid clicks and let
> them communicate through OSC. For instance last friday I had an exhibition
> of an installation doing motion tracking, video replay in 3D environment for
> simple mapping and audio synthesis and had three PD instances running.
> Worked fine on a small EEE netbook but that approach takes away that benefit
> you mentioned to have all together in one patch.
>
> Cheers,
>
> Malte
> --
> ----
> media art + development
> http://www.block4.com
>
> 15.5. Notstandskomitee @ Placard Festival 23:30
> Druckerei Gaengeviertel Hamburg
>
>
> 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"

On 14.05.2010 15:15, Rory Walsh wrote:
> Hi Malte, when you say three instance are you talking about three
> instances running on one machine, or 3 instance on three separate
> machines?
three instances of PD on one machine, a small EEE netbook. That 
exhibition had limited space, it was in an elevator lift! No access to 
power supply so we ran that netbook, a pocket video projector and USB 
powerd speakers on the built-in batteries. Everything went well, the 
projector was empty first after nearly 4 hours which was the time 
expected for the exhibition to last. Then came the netbook which should 
last much longer (its the one Asus claim 11 hours batterytime) but it 
was feeding the speakers and a USB2.0 webcam too and had no CPU 
freqscaling so its ok I guess. BTW pocket projectors are pretty cool, 
just saw the current RESIDENTS concert with them using it for handheld 
projections.

Thinking about running my concert tomorrow from that netbook, its a huge 
CSound patch hopefully the Atom processor can cope with. Realtime kernel 
is already compiled.

Cheers,

Malte

Wow, Sounds like you got a lot of juice out of that Atom. Impressive.
Oeyvind

2010/5/14 Malte Steiner :
> On 14.05.2010 15:15, Rory Walsh wrote:
>>
>> Hi Malte, when you say three instance are you talking about three
>> instances running on one machine, or 3 instance on three separate
>> machines?
>
> three instances of PD on one machine, a small EEE netbook. That exhibition
> had limited space, it was in an elevator lift! No access to power supply so
> we ran that netbook, a pocket video projector and USB powerd speakers on the
> built-in batteries. Everything went well, the projector was empty first
> after nearly 4 hours which was the time expected for the exhibition to last.
> Then came the netbook which should last much longer (its the one Asus claim
> 11 hours batterytime) but it was feeding the speakers and a USB2.0 webcam
> too and had no CPU freqscaling so its ok I guess. BTW pocket projectors are
> pretty cool, just saw the current RESIDENTS concert with them using it for
> handheld projections.
>
> Thinking about running my concert tomorrow from that netbook, its a huge
> CSound patch hopefully the Atom processor can cope with. Realtime kernel is
> already compiled.
>
> Cheers,
>
> Malte
> --
> ----
> media art + development
> http://www.block4.com
>
> 15.5. Notstandskomitee @ Placard Festival 23:30
> Druckerei Gaengeviertel Hamburg
>
>
> 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"

On 14.05.2010 17:33, Oeyvind Brandtsegg wrote:
> Wow, Sounds like you got a lot of juice out of that Atom. Impressive.
It was not so much synthesis going on, more replaying of audio- and 
videofiles. Most processing happend in the color tracking with the PiDiP 
externals of PD.

Cheers,

Malte