So is it possible to do live coding like impromptu and supercollider with
python and CSOUND ? Can you point me to the right direction with a link ?

I have read about the AthenaCL and CSOUNDAC, I also saw the new python 
opcodes in version 5, but can all those used real time ?

Hi,

Currently you can live code Csound, but only the score/note events.
The audio graph is fixed. I also wished the audio graph could be
modified while running...
You can do this within Python (or C, Lua, etc.) itself, or with the
Live Event Sheet in QuteCsound.

OTOH, There's the Ounk project, which spawns Csound instances
automatically, so you feel like you are live coding a la
SuperCollider, but AFAIK it's not the full Csound:

http://code.google.com/p/ounk/

Cheers,
Andrés

On Wed, Jul 7, 2010 at 1:04 PM, Anthony Palomba  wrote:
> This is currently not possible in Csound. One of the things that SC
> allows you to do is build a signal path in real time. CSound parses
> your orchestra file before hand and does not allow you to change it.
>
> But I think this functionality will be added to CSound soon
> (at least I hope). I would love to be able to have the ability to
> procedurally model my instruments and score events in real time,
> like SuperCollider.
>
>
>
>
> -ap
>
>
>
>
> On Wed, Jul 7, 2010 at 1:58 AM, kilon  wrote:
>>
>> So is it possible to do live coding like impromptu and supercollider with
>> python and CSOUND ? Can you point me to the right direction with a link ?
>>
>> I have read about the AthenaCL and CSOUNDAC, I also saw the new python
>> opcodes in version 5, but can all those used real time ?
>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Using-python-with-CSOUND-for-Livecoding-like-Supercollider-tp29093213p29093213.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"

Also, Ounk is not maintained anymore...

./mdd

-----Message d'origine-----
De : Andres Cabrera [mailto:mantaraya36@gmail.com] 
Envoyé : 7 juillet 2010 11:14
À : csound@lists.bath.ac.uk
Objet : [Csnd] Re: Re: Using python with CSOUND for Livecoding like Supercollider

Hi,

Currently you can live code Csound, but only the score/note events.
The audio graph is fixed. I also wished the audio graph could be
modified while running...
You can do this within Python (or C, Lua, etc.) itself, or with the
Live Event Sheet in QuteCsound.

OTOH, There's the Ounk project, which spawns Csound instances
automatically, so you feel like you are live coding a la
SuperCollider, but AFAIK it's not the full Csound:

http://code.google.com/p/ounk/

Cheers,
Andrés

On Wed, Jul 7, 2010 at 1:04 PM, Anthony Palomba  wrote:
> This is currently not possible in Csound. One of the things that SC
> allows you to do is build a signal path in real time. CSound parses
> your orchestra file before hand and does not allow you to change it.
>
> But I think this functionality will be added to CSound soon
> (at least I hope). I would love to be able to have the ability to
> procedurally model my instruments and score events in real time,
> like SuperCollider.
>
>
>
>
> -ap
>
>
>
>
> On Wed, Jul 7, 2010 at 1:58 AM, kilon  wrote:
>>
>> So is it possible to do live coding like impromptu and supercollider with
>> python and CSOUND ? Can you point me to the right direction with a link ?
>>
>> I have read about the AthenaCL and CSOUNDAC, I also saw the new python
>> opcodes in version 5, but can all those used real time ?
>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Using-python-with-CSOUND-for-Livecoding-like-Supercollider-tp29093213p29093213.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"




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"

Yes, I'm a SC user and I love it. Both scsynth (the server) and sclang
(the language).  SCLang have a lot in common with python BTW. But
SuperCollider wouldn't be possible if CSound didn't reach its place in
non-real-time synthesis. I'm sure SuperCollider gained a lot with
CSound free software project. CSound is a very good software and has
LOT of credit. SuperCollider is also free software and is being
vigorously developed. I just wonder if instead of spreading effords
with is two amazing software projects wound not make more sense to
concentrate software development for real-time synthesis with
SuperCollider?


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"

Although...  you can dynamically change the audio routing between
instruments using zak or the mixer opcodes. This you could control via
python.

I wonder how far you'd get if you wrapped a bunch of opcodes in
instrument defs and built a graph that way...


TK






On Thu, Jul 8, 2010 at 1:13 AM, Andres Cabrera  wrote:
> Hi,
>
> Currently you can live code Csound, but only the score/note events.
> The audio graph is fixed. I also wished the audio graph could be
> modified while running...
> You can do this within Python (or C, Lua, etc.) itself, or with the
> Live Event Sheet in QuteCsound.
>
> OTOH, There's the Ounk project, which spawns Csound instances
> automatically, so you feel like you are live coding a la
> SuperCollider, but AFAIK it's not the full Csound:
>
> http://code.google.com/p/ounk/
>
> Cheers,
> Andrés
>
> On Wed, Jul 7, 2010 at 1:04 PM, Anthony Palomba  wrote:
>> This is currently not possible in Csound. One of the things that SC
>> allows you to do is build a signal path in real time. CSound parses
>> your orchestra file before hand and does not allow you to change it.
>>
>> But I think this functionality will be added to CSound soon
>> (at least I hope). I would love to be able to have the ability to
>> procedurally model my instruments and score events in real time,
>> like SuperCollider.
>>
>>
>>
>>
>> -ap
>>
>>
>>
>>
>> On Wed, Jul 7, 2010 at 1:58 AM, kilon  wrote:
>>>
>>> So is it possible to do live coding like impromptu and supercollider with
>>> python and CSOUND ? Can you point me to the right direction with a link ?
>>>
>>> I have read about the AthenaCL and CSOUNDAC, I also saw the new python
>>> opcodes in version 5, but can all those used real time ?
>>>
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Using-python-with-CSOUND-for-Livecoding-like-Supercollider-tp29093213p29093213.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"
>
>


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 Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
 wrote:

> Live-coded
> pieces always sound more dead than some of the oldest Music-N pieces (Stria
> for instance)!

I think this is a bit of a generalisation...

One of the first live coded pieces I came across is also one of the
most 'alive' sounding works I know. You can see it here:
http://vimeo.com/groups/impromptu/videos/2433947

I wouldn't have believed it was live coded unless I saw it performed
with my own eyes. Of course, this is 'algorithmic' live coding using
Impromptu (which can easily use Csound as a synth via OSC, and could
probably use the API as well). I can imagine watching someone going to
great efforts to live-code an FM algorithm might be tedious to watch.

Tk


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"

This has certainly been an interest of mine from an application
developer perspective(blue), but I don't think there's been any active
development on it. We've discussed what's necessary on the dev mailing
list a few times however.  The big issue is the symbol table is erased
after compilation meaning an in-performance structure could not get
modified, only replaced.  That may not be a huge issue in the end, and
perhaps that's alright for a first step.

Maybe a formal design document would be a good step to get an engine
more aligned to real-time modification.

Does anyone know in SuperCollider, can you modify parts of a SynthDef,
or only replace one as a whole?  If you redefine a SynthDef when it is
active, what happens?

On Wed, Jul 7, 2010 at 1:44 PM, Anthony Palomba  wrote:
> I don't know why we are bringing up "live coding". I certainly
> do not want to do live coding with csound.
>
> But I do believe that being able to build instrument
> signal paths in real time is valuable because I can
> model structures on the instrument level as opposed
> to figuring out how to emulate them in the score.
>
> I could dynamically create as many oscilattors as
> I want and connect them in any configuration. Then
> apply effects various sub mixes.
>
> Having the power to do this in real-time means I could easily
> create as many permutations of this process as I wanted.
> The significantly speeds up the creative process of exploration.
>
> So is this on the road map?
>
>
>
> -ap
>
>
>
>
> On Wed, Jul 7, 2010 at 12:14 PM, Peiman Khosravi 
> wrote:
>>
>> Hello,
>> On 7 Jul 2010, at 17:27, Aaron Krister Johnson wrote:
>>
>> I feel your pain Anthony. As much as I LOVE Csound, it's not keeping up
>> with what a growing population of musicians "are doing/want to be able to
>> do" these days, it seems. I fear it to be a dead language except for certain
>> non-RT things, and it will certainly maintain a niche for sonic research, I
>> guess.
>>
>>
>> This seems like a bit of a generalisation. Nothing offers everything (try
>> doing some FFT in SC3 that sounds as good as Csound's pvs opcodes). By the
>> "growing population of musicians" are you just referring to live coders? My
>> prediction is that Csound will stick around for much longer than live coding
>> will. Seriously I don't thing there is anything to live-coding other than
>> being a bit of fun. I don't see the point and I don't see why valuable
>> development time should be spend implementing it in Csound. Live-coded
>> pieces always sound more dead than some of the oldest Music-N pieces (Stria
>> for instance)!
>> I agree that as a language SC is much neater than SC3 but I don't think
>> that Csound is going to die because of that.
>>
>> Best,
>> Peiman
>>
>> I've been recently checking out SuperCollider. I'm *very* impressed with
>> it's robustness with RT loads, and it seems a much more compact language
>> than Csound, too. OTOH, it's a new paradigm; I'm used to the way Csound
>> works, and have invested a lot into learning Csound. Maybe I'll flirt with
>> SuperCollider for a while and wait to see what becomes of Csound in the long
>> haul. NO problem to know both, after all, and use the strength of both.
>>
>> I've noticed that Csound seems to keep bugs around for a long time. I
>> mentioned twice on these lists a bug about libwii being a necessity under
>> compiling, and I was perplexed to find that a year or more later, the same
>> issue existed.....seems awfully baroque in it's build and install too, as
>> Dr. B. has oft reiterated. And SuperCollider has some neat opcodes (ex.
>> Gendy oscillators) that I won't hold my breath waiting for Csound to
>> get.....Csound does have some opcodes that are superior to SuperCollider's
>> (like I think the granular stuff in Csound is particularly strong), but
>> typically SC has similar/better opcodes than Csound for the same
>> need....also Csound has opcodes that are in the manual, but they just don't
>> work AT ALL....(all the stuff that uses HETRO is utterly broken in my
>> experience, and has anyone figured out LORIS stuff?)
>>
>> For RT needs, SuperCollider also seems WAY more robust for live use, being
>> a server/client architecture, and it generally feels faster and less
>> choppy.....maybe that's b/c it's designed ground up for such purposes.....
>>
>> It's a mixed bag!!!!
>>
>> AKJ
>>
>> On Wed, Jul 7, 2010 at 10:34 AM, Anthony Palomba 
>> wrote:
>>>
>>> Does anyone have an idea as to when we will have the ability
>>> to build a signal chain in real-time via python?
>>>
>>> Is this on the road map?
>>>
>>>
>>> -ap
>>>
>>>
>>>
>>> On Wed, Jul 7, 2010 at 10:13 AM, Andres Cabrera 
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Currently you can live code Csound, but only the score/note events.
>>>> The audio graph is fixed. I also wished the audio graph could be
>>>> modified while running...
>>>> You can do this within Python (or C, Lua, etc.) itself, or with the
>>>> Live Event Sheet in QuteCsound.
>>>>
>>>> OTOH, There's the Ounk project, which spawns Csound instances
>>>> automatically, so you feel like you are live coding a la
>>>> SuperCollider, but AFAIK it's not the full Csound:
>>>>
>>>> http://code.google.com/p/ounk/
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>> On Wed, Jul 7, 2010 at 1:04 PM, Anthony Palomba 
>>>> wrote:
>>>> > This is currently not possible in Csound. One of the things that SC
>>>> > allows you to do is build a signal path in real time. CSound parses
>>>> > your orchestra file before hand and does not allow you to change it.
>>>> >
>>>> > But I think this functionality will be added to CSound soon
>>>> > (at least I hope). I would love to be able to have the ability to
>>>> > procedurally model my instruments and score events in real time,
>>>> > like SuperCollider.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > -ap
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Jul 7, 2010 at 1:58 AM, kilon  wrote:
>>>> >>
>>>> >> So is it possible to do live coding like impromptu and supercollider
>>>> >> with
>>>> >> python and CSOUND ? Can you point me to the right direction with a
>>>> >> link ?
>>>> >>
>>>> >> I have read about the AthenaCL and CSOUNDAC, I also saw the new
>>>> >> python
>>>> >> opcodes in version 5, but can all those used real time ?
>>>> >>
>>>> >>
>>>> >> --
>>>> >> View this message in context:
>>>> >>
>>>> >> http://old.nabble.com/Using-python-with-CSOUND-for-Livecoding-like-Supercollider-tp29093213p29093213.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"
>>>>
>>>
>>
>>
>>
>> --
>> Best,
>>
>> Aaron Krister Johnson
>> http://www.akjmusic.com
>> http://www.untwelve.org
>>
>>
>
>


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 Wed, Jul 7, 2010 at 10:56 AM, Steven Yi  wrote:
> Maybe a formal design document would be a good step to get an engine
> more aligned to real-time modification.

I know this isn't the most popular idea on the list. I recommend that
Csound 6 breaks backwards compatibility in favor of a new design. It
would liberate Csound and allow many issues, inclluding real-time
instrument creation and patching, to be properly addressed.

Best,
Jake

2010/7/7 Steven Yi :
> Does anyone know in SuperCollider, can you modify parts of a SynthDef,
> or only replace one as a whole?  If you redefine a SynthDef when it is
> active, what happens?

If you change a SynthDef (server side) this will not make anything to
Synths already running, but new Synths will be different. But  has
different "coding styles". This is the original. But there is also
JITLib that you can change synthfs in runtime (with fadeTime or not)
and not think at all about SynthDefs.


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 means a LOT of work, doesn't it? Really, again.., why spread like
this the development work and talent?
Why implement things in Python and redesign CSound just to make it do
what SC is doing well. If SC is not perfect, why not make it even
better?

2010/7/7 Jacob Joaquin :
> On Wed, Jul 7, 2010 at 10:56 AM, Steven Yi  wrote:
>> Maybe a formal design document would be a good step to get an engine
>> more aligned to real-time modification.
>
> I know this isn't the most popular idea on the list. I recommend that
> Csound 6 breaks backwards compatibility in favor of a new design. It
> would liberate Csound and allow many issues, inclluding real-time
> instrument creation and patching, to be properly addressed.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
> Slipmat - http://slipmat.noisepages.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"

On Wed, Jul 7, 2010 at 11:27 AM, Bernardo Barros
 wrote:
> That means a LOT of work, doesn't it? Really, again.., why spread like
> this the development work and talent?
> Why implement things in Python and redesign CSound just to make it do
> what SC is doing well. If SC is not perfect, why not make it even
> better?

It wouldn't so much to make Csound more like SC, but to allow Csound
to reach it's full potential. There are so many things working against
it, without even considering what other languages are or are not
doing.

Best,
Jake

2010/7/7 Aaron Krister Johnson :
> I don't know if there's something even more instant than that in some other
> environment. I imagine that if you want a parameter to update instantly,
> you'd have to implement a GUI, or send messages from some kind of text-based
> OSC interface.

Well, SynthDefs have arguments. You just need to set the args of your
Synth while it is running (with text, gui, osc, midi or whatever).
That's the good practice for this coding style. This can be very flexible btw.

But... if you want to really change the SynthDef code, better to use
another code style like JIT-Lib.


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"

Also SC is having exciting development now with multi-processor aware
scsynth (from the supernova project) and cross-platform GUI system
with qt4 (there is just native cocoa and java SwingOSC now). Also you
can control scsynth without sclang with python or scala (there is a
scalacollider project too)

2010/7/7 Bernardo Barros :
> 2010/7/7 Aaron Krister Johnson :
>> I don't know if there's something even more instant than that in some other
>> environment. I imagine that if you want a parameter to update instantly,
>> you'd have to implement a GUI, or send messages from some kind of text-based
>> OSC interface.
>
> Well, SynthDefs have arguments. You just need to set the args of your
> Synth while it is running (with text, gui, osc, midi or whatever).
> That's the good practice for this coding style. This can be very flexible btw.
>
> But... if you want to really change the SynthDef code, better to use
> another code style like JIT-Lib.
>


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"

Not very far, I'm afraid. I'm not sure all the required sorts of
abstraction are there, and even if they are and an instrument def
graph could be made with instrument defs, the way the signal flow
opcodes manage instances is not efficient enough.

That said, I have various prototypes of this sort of thing that I have
implemented to the point of  being able to get some sort of a sound
out -- not in Csound, as stand-alone programmable software
synthesizers.

A major design issue is whether to extend the signal flow graph all
the way down to atomic DSP and math and logic operations, or to stop
the graph at the instrument/effect level and then use regular
procedural programming. Currently synthesizers use a complete graph,
and any procedural code (such as Csound instrument definitions or
SuperCollider insdefs) is compiled into its own graph. I am not sure
this is the best way to go.

My current conceptual design uses a signal flow graph from the
instrument/effect level on up, including inputs and outputs. Within
instrument definitions, there is procedural Lua, Python, or maybe even
C++ code. The signal flow graph is live codable. With a dynamic
language such as Lua or Python, the instrument definitions also would
be live codable. I suspect, however, that the glue code between the
C++ signal flow graph and the dynamic language instruments would add
too much overhead.

The design is automatically multi-threaded in the signal flow graph,
and if the instrument definitions don't share objects, they can be
multi-threaded within the graph (but different mechanisms would be
required to multi-thread within the instrument definitions).

GCC is mature enough that in all likelihood, you could spawn a thread
or process to compile a C++ instrument definition and plug it into the
signal flow graph quickly enough to seem "live," so I might just stick
with C++ with a "building shell" that is part of the system.

So far, about 90% thoughts and 10% code. However, I'm quite confident
that the pure C++, live compiling/load shared library instrument into
running graph approach not only would work, but would be at least as
efficient and easy to code/maintain as any other design.

There's some precedent for the live compiling of C++ in scientific programming.

Regards,
Mike

On Wed, Jul 7, 2010 at 1:11 PM, thorin kerr  wrote:
> Although...  you can dynamically change the audio routing between
> instruments using zak or the mixer opcodes. This you could control via
> python.
>
> I wonder how far you'd get if you wrapped a bunch of opcodes in
> instrument defs and built a graph that way...
>
>
> TK
>
>
>
>
>
>
> On Thu, Jul 8, 2010 at 1:13 AM, Andres Cabrera  wrote:
>> Hi,
>>
>> Currently you can live code Csound, but only the score/note events.
>> The audio graph is fixed. I also wished the audio graph could be
>> modified while running...
>> You can do this within Python (or C, Lua, etc.) itself, or with the
>> Live Event Sheet in QuteCsound.
>>
>> OTOH, There's the Ounk project, which spawns Csound instances
>> automatically, so you feel like you are live coding a la
>> SuperCollider, but AFAIK it's not the full Csound:
>>
>> http://code.google.com/p/ounk/
>>
>> Cheers,
>> Andrés
>>
>> On Wed, Jul 7, 2010 at 1:04 PM, Anthony Palomba  wrote:
>>> This is currently not possible in Csound. One of the things that SC
>>> allows you to do is build a signal path in real time. CSound parses
>>> your orchestra file before hand and does not allow you to change it.
>>>
>>> But I think this functionality will be added to CSound soon
>>> (at least I hope). I would love to be able to have the ability to
>>> procedurally model my instruments and score events in real time,
>>> like SuperCollider.
>>>
>>>
>>>
>>>
>>> -ap
>>>
>>>
>>>
>>>
>>> On Wed, Jul 7, 2010 at 1:58 AM, kilon  wrote:
>>>>
>>>> So is it possible to do live coding like impromptu and supercollider with
>>>> python and CSOUND ? Can you point me to the right direction with a link ?
>>>>
>>>> I have read about the AthenaCL and CSOUNDAC, I also saw the new python
>>>> opcodes in version 5, but can all those used real time ?
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/Using-python-with-CSOUND-for-Livecoding-like-Supercollider-tp29093213p29093213.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"
>>
>>
>
>
> 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"

WOW alot of detailed replies, thank you guys, I really appreciate it. It
seems I have to take a deeper look at SC.

I agree CSOUND is great for offline rendering of sounds, its literally
limitless.  


kilon wrote:
> 
> So is it possible to do live coding like impromptu and supercollider with
> python and CSOUND ? Can you point me to the right direction with a link ?
> 
> I have read about the AthenaCL and CSOUNDAC, I also saw the new python 
> opcodes in version 5, but can all those used real time ?
> 
> 
> 

Hi,

Do you have a link to controlling scsynth from python?

Cheers,
Andrés

On Wed, Jul 7, 2010 at 8:23 PM, Bernardo Barros
 wrote:
> Also SC is having exciting development now with multi-processor aware
> scsynth (from the supernova project) and cross-platform GUI system
> with qt4 (there is just native cocoa and java SwingOSC now). Also you
> can control scsynth without sclang with python or scala (there is a
> scalacollider project too)
>
> 2010/7/7 Bernardo Barros :
>> 2010/7/7 Aaron Krister Johnson :
>>> I don't know if there's something even more instant than that in some other
>>> environment. I imagine that if you want a parameter to update instantly,
>>> you'd have to implement a GUI, or send messages from some kind of text-based
>>> OSC interface.
>>
>> Well, SynthDefs have arguments. You just need to set the args of your
>> Synth while it is running (with text, gui, osc, midi or whatever).
>> That's the good practice for this coding style. This can be very flexible btw.
>>
>> But... if you want to really change the SynthDef code, better to use
>> another code style like JIT-Lib.
>>
>
>
> 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"

Yes of course it was a generalisation :-)

My point was that I don't see the point of live-coding because I don't  
find it musically interesting to watch someone write code (or possibly  
check their email!). Why not write the code in the studio and render  
it beforehand? Of course live-coded pieces may be interesting or even  
amazing (even if they rarely are), but that has nothing to do with the  
fact that they were live-coded. Live-coding as a paradigm is flawed as  
far as I am concerned. For a start what's the point of seeing a bunch  
of random lines on the screen if you don't understand the language?

Of course it would be nice to be able to build signal path in real- 
time with csound. But for me it isn't a great disadvantage not to have  
that, and I certainly don't think Csound will die because of it!

P

On 7 Jul 2010, at 18:41, thorin kerr wrote:

> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>  wrote:
>
>> Live-coded
>> pieces always sound more dead than some of the oldest Music-N  
>> pieces (Stria
>> for instance)!
>
> I think this is a bit of a generalisation...
>
> One of the first live coded pieces I came across is also one of the
> most 'alive' sounding works I know. You can see it here:
> http://vimeo.com/groups/impromptu/videos/2433947
>
> I wouldn't have believed it was live coded unless I saw it performed
> with my own eyes. Of course, this is 'algorithmic' live coding using
> Impromptu (which can easily use Csound as a synth via OSC, and could
> probably use the API as well). I can imagine watching someone going to
> great efforts to live-code an FM algorithm might be tedious to watch.
>
> Tk
>
>
> 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"

>
> Don't pay TOO much attention to what I'm saying. I do think the  
> relevant critiques of Csound largely have to do with broken  
> installs, broken opcodes, broken manual examples, etc. more than  
> it's ultimate power...IOW, end user experience stuff at an 'instant  
> appeal' level.
> Things like Iain McCurdy's GUI frontends I think would do a  
> tremendous amount of good to change that, as I imagine Blue and  
> QuteCsound do, but I still refuse to install either b/c they would  
> be the only reason to install Java and QT for me!!! :) (although now  
> that I have SC, I might check out Blue, and see if it runs with my  
> local jre that I put on my laptop for SwingOSC toolkit usage.....
>

Talking about dead/deprecated opcodes.

I think it would do Csound a lot of good if there was a parallel  
release that only included a selected number of thoroughly tested  
opcodes that work in real-time and in both float/double builds (e.g.  
out of all the fft opcodes keep the pvs and so on). Keep the bear  
minimum and get rid of everything else. Even if it's just a one of  
release to see how the community responds.

In any case would it be possible to define which opcodes are built  
when compiling Csound if someone wants to do that?

Another pain is that csound installs files in numerous places  
(libraries, binaries, then you have float/double, it's too  
convoluted). It would certainly be better if it was all in one place  
and it was a matter of drag and dropping the folder (like SC). For  
that reason I actually preferred the installation method of csound 4.  
I think that's certainly on my wish list for csound 6.

P


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"

2010/7/8 Andres Cabrera :
> Hi,
>
> Do you have a link to controlling scsynth from python?
>

http://pypi.python.org/pypi/SC/0.2

(but sclang is also very good :-)


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 don't do live coding, but I am interested in it. Anything that
reduces the amount of time between conception and hearing in computer
music appeals to me. The faster things go, the more sounds you can
explore.

So, although I don't do live coding, I have done a great deal of work
to make my own composing environment more efficient:

-- I have a standard "template" script with built-in options for
testing the Csound orchestra, rendering in real-time, or rendering to
soundfile.

-- I have a standard Csound orchestra that actually contains all my
interesting instruments, patched into a signal flow graph with
mastering effects. I just re-arrange the instruments to suit the needs
of each piece. The instruments all use the same pfields and are
normalized in loudness.

-- When rendering to soundfile, the template automatically rescales
the output, creates an MP3, and writes tags, then opens the master
soundfile in a player. This means when the piece sounds good to me, it
is actually finished, and I can just upload the MP3 or burn a CD.

As a result, I can work pretty rapidly, generating dozens of pieces in
a working session.

The main hangup in this setup is that my pieces generally are too
dense to render in real time, so I have to twiddle my thumbs while the
pieces render, normalize, etc. But the next computer I get will be at
least quad core and the disk will be faster, too.

Which reminds me -- when is the ParCS branch going to be merged?

Regards,
Mike


On Thu, Jul 8, 2010 at 7:49 AM, Peiman Khosravi
 wrote:
> Yes of course it was a generalisation :-)
>
> My point was that I don't see the point of live-coding because I don't find
> it musically interesting to watch someone write code (or possibly check
> their email!). Why not write the code in the studio and render it
> beforehand? Of course live-coded pieces may be interesting or even amazing
> (even if they rarely are), but that has nothing to do with the fact that
> they were live-coded. Live-coding as a paradigm is flawed as far as I am
> concerned. For a start what's the point of seeing a bunch of random lines on
> the screen if you don't understand the language?
>
> Of course it would be nice to be able to build signal path in real-time with
> csound. But for me it isn't a great disadvantage not to have that, and I
> certainly don't think Csound will die because of it!
>
> P
>
> On 7 Jul 2010, at 18:41, thorin kerr wrote:
>
>> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>>  wrote:
>>
>>> Live-coded
>>> pieces always sound more dead than some of the oldest Music-N pieces
>>> (Stria
>>> for instance)!
>>
>> I think this is a bit of a generalisation...
>>
>> One of the first live coded pieces I came across is also one of the
>> most 'alive' sounding works I know. You can see it here:
>> http://vimeo.com/groups/impromptu/videos/2433947
>>
>> I wouldn't have believed it was live coded unless I saw it performed
>> with my own eyes. Of course, this is 'algorithmic' live coding using
>> Impromptu (which can easily use Csound as a synth via OSC, and could
>> probably use the API as well). I can imagine watching someone going to
>> great efforts to live-code an FM algorithm might be tedious to watch.
>>
>> Tk
>>
>>
>> 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"

Interestingly, I have a friend who composes only with SC3. Including  
mixing and everything. As his projects get larger and denser he runs  
out of processing power and has to move to protools to mix the layers  
together.

And apparently it is more hassle to use SC3 in non-real-time than in  
real-time (I don't know if this is true as I've never used SC3 in non- 
real-time mode).

The one things that does slow down the work-flaw in csound for me is  
the need to define a score event for every instrument. It would indeed  
be nice to be able to write an instrument and include some sort of  
'play' command inside the instrument that starts performance  
indefinitely. Eliminating the need to have a score section all together.

Thinking about it, it would also be great to be able to try opcodes  
and create signal paths without the need to define an instrument!  
Mhhhh not sure how that would work but there may be a logical way of  
implementing it???

P

On 8 Jul 2010, at 14:28, Michael Gogins wrote:

> I don't do live coding, but I am interested in it. Anything that
> reduces the amount of time between conception and hearing in computer
> music appeals to me. The faster things go, the more sounds you can
> explore.
>
> So, although I don't do live coding, I have done a great deal of work
> to make my own composing environment more efficient:
>
> -- I have a standard "template" script with built-in options for
> testing the Csound orchestra, rendering in real-time, or rendering to
> soundfile.
>
> -- I have a standard Csound orchestra that actually contains all my
> interesting instruments, patched into a signal flow graph with
> mastering effects. I just re-arrange the instruments to suit the needs
> of each piece. The instruments all use the same pfields and are
> normalized in loudness.
>
> -- When rendering to soundfile, the template automatically rescales
> the output, creates an MP3, and writes tags, then opens the master
> soundfile in a player. This means when the piece sounds good to me, it
> is actually finished, and I can just upload the MP3 or burn a CD.
>
> As a result, I can work pretty rapidly, generating dozens of pieces in
> a working session.
>
> The main hangup in this setup is that my pieces generally are too
> dense to render in real time, so I have to twiddle my thumbs while the
> pieces render, normalize, etc. But the next computer I get will be at
> least quad core and the disk will be faster, too.
>
> Which reminds me -- when is the ParCS branch going to be merged?
>
> Regards,
> Mike
>
>
> On Thu, Jul 8, 2010 at 7:49 AM, Peiman Khosravi
>  wrote:
>> Yes of course it was a generalisation :-)
>>
>> My point was that I don't see the point of live-coding because I  
>> don't find
>> it musically interesting to watch someone write code (or possibly  
>> check
>> their email!). Why not write the code in the studio and render it
>> beforehand? Of course live-coded pieces may be interesting or even  
>> amazing
>> (even if they rarely are), but that has nothing to do with the fact  
>> that
>> they were live-coded. Live-coding as a paradigm is flawed as far as  
>> I am
>> concerned. For a start what's the point of seeing a bunch of random  
>> lines on
>> the screen if you don't understand the language?
>>
>> Of course it would be nice to be able to build signal path in real- 
>> time with
>> csound. But for me it isn't a great disadvantage not to have that,  
>> and I
>> certainly don't think Csound will die because of it!
>>
>> P
>>
>> On 7 Jul 2010, at 18:41, thorin kerr wrote:
>>
>>> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>>>  wrote:
>>>
>>>> Live-coded
>>>> pieces always sound more dead than some of the oldest Music-N  
>>>> pieces
>>>> (Stria
>>>> for instance)!
>>>
>>> I think this is a bit of a generalisation...
>>>
>>> One of the first live coded pieces I came across is also one of the
>>> most 'alive' sounding works I know. You can see it here:
>>> http://vimeo.com/groups/impromptu/videos/2433947
>>>
>>> I wouldn't have believed it was live coded unless I saw it performed
>>> with my own eyes. Of course, this is 'algorithmic' live coding using
>>> Impromptu (which can easily use Csound as a synth via OSC, and could
>>> probably use the API as well). I can imagine watching someone  
>>> going to
>>> great efforts to live-code an FM algorithm might be tedious to  
>>> watch.
>>>
>>> Tk
>>>
>>>
>>> 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"
>



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 generate score events from inside instruments. You can also
schedule an instrument instance to be always on.

You would, however, have to do something to guard against endless
recursion. Something like this:

alwayson myinstrument ... 1

instr myinstrument
if myflag == 1 then
schedule "myinstrument", ...,0
endif
;make some noise
endin

Regards,
Mike

On Thu, Jul 8, 2010 at 9:38 AM, Peiman Khosravi
 wrote:
> Interestingly, I have a friend who composes only with SC3. Including mixing
> and everything. As his projects get larger and denser he runs out of
> processing power and has to move to protools to mix the layers together.
>
> And apparently it is more hassle to use SC3 in non-real-time than in
> real-time (I don't know if this is true as I've never used SC3 in
> non-real-time mode).
>
> The one things that does slow down the work-flaw in csound for me is the
> need to define a score event for every instrument. It would indeed be nice
> to be able to write an instrument and include some sort of 'play' command
> inside the instrument that starts performance indefinitely. Eliminating the
> need to have a score section all together.
>
> Thinking about it, it would also be great to be able to try opcodes and
> create signal paths without the need to define an instrument! Mhhhh not sure
> how that would work but there may be a logical way of implementing it???
>
> P
>
> On 8 Jul 2010, at 14:28, Michael Gogins wrote:
>
>> I don't do live coding, but I am interested in it. Anything that
>> reduces the amount of time between conception and hearing in computer
>> music appeals to me. The faster things go, the more sounds you can
>> explore.
>>
>> So, although I don't do live coding, I have done a great deal of work
>> to make my own composing environment more efficient:
>>
>> -- I have a standard "template" script with built-in options for
>> testing the Csound orchestra, rendering in real-time, or rendering to
>> soundfile.
>>
>> -- I have a standard Csound orchestra that actually contains all my
>> interesting instruments, patched into a signal flow graph with
>> mastering effects. I just re-arrange the instruments to suit the needs
>> of each piece. The instruments all use the same pfields and are
>> normalized in loudness.
>>
>> -- When rendering to soundfile, the template automatically rescales
>> the output, creates an MP3, and writes tags, then opens the master
>> soundfile in a player. This means when the piece sounds good to me, it
>> is actually finished, and I can just upload the MP3 or burn a CD.
>>
>> As a result, I can work pretty rapidly, generating dozens of pieces in
>> a working session.
>>
>> The main hangup in this setup is that my pieces generally are too
>> dense to render in real time, so I have to twiddle my thumbs while the
>> pieces render, normalize, etc. But the next computer I get will be at
>> least quad core and the disk will be faster, too.
>>
>> Which reminds me -- when is the ParCS branch going to be merged?
>>
>> Regards,
>> Mike
>>
>>
>> On Thu, Jul 8, 2010 at 7:49 AM, Peiman Khosravi
>>  wrote:
>>>
>>> Yes of course it was a generalisation :-)
>>>
>>> My point was that I don't see the point of live-coding because I don't
>>> find
>>> it musically interesting to watch someone write code (or possibly check
>>> their email!). Why not write the code in the studio and render it
>>> beforehand? Of course live-coded pieces may be interesting or even
>>> amazing
>>> (even if they rarely are), but that has nothing to do with the fact that
>>> they were live-coded. Live-coding as a paradigm is flawed as far as I am
>>> concerned. For a start what's the point of seeing a bunch of random lines
>>> on
>>> the screen if you don't understand the language?
>>>
>>> Of course it would be nice to be able to build signal path in real-time
>>> with
>>> csound. But for me it isn't a great disadvantage not to have that, and I
>>> certainly don't think Csound will die because of it!
>>>
>>> P
>>>
>>> On 7 Jul 2010, at 18:41, thorin kerr wrote:
>>>
>>>> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>>>>  wrote:
>>>>
>>>>> Live-coded
>>>>> pieces always sound more dead than some of the oldest Music-N pieces
>>>>> (Stria
>>>>> for instance)!
>>>>
>>>> I think this is a bit of a generalisation...
>>>>
>>>> One of the first live coded pieces I came across is also one of the
>>>> most 'alive' sounding works I know. You can see it here:
>>>> http://vimeo.com/groups/impromptu/videos/2433947
>>>>
>>>> I wouldn't have believed it was live coded unless I saw it performed
>>>> with my own eyes. Of course, this is 'algorithmic' live coding using
>>>> Impromptu (which can easily use Csound as a synth via OSC, and could
>>>> probably use the API as well). I can imagine watching someone going to
>>>> great efforts to live-code an FM algorithm might be tedious to watch.
>>>>
>>>> Tk
>>>>
>>>>
>>>> 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"
>>
>
>
>
> 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"

Nice one, thanks!!

Where do you define the value of myflag?

P

On 8 Jul 2010, at 15:42, Michael Gogins wrote:

> You can generate score events from inside instruments. You can also
> schedule an instrument instance to be always on.
>
> You would, however, have to do something to guard against endless
> recursion. Something like this:
>
> alwayson myinstrument ... 1
>
> instr myinstrument
> if myflag == 1 then
> schedule "myinstrument", ...,0
> endif
> ;make some noise
> endin
>
> Regards,
> Mike
>
> On Thu, Jul 8, 2010 at 9:38 AM, Peiman Khosravi
>  wrote:
>> Interestingly, I have a friend who composes only with SC3.  
>> Including mixing
>> and everything. As his projects get larger and denser he runs out of
>> processing power and has to move to protools to mix the layers  
>> together.
>>
>> And apparently it is more hassle to use SC3 in non-real-time than in
>> real-time (I don't know if this is true as I've never used SC3 in
>> non-real-time mode).
>>
>> The one things that does slow down the work-flaw in csound for me  
>> is the
>> need to define a score event for every instrument. It would indeed  
>> be nice
>> to be able to write an instrument and include some sort of 'play'  
>> command
>> inside the instrument that starts performance indefinitely.  
>> Eliminating the
>> need to have a score section all together.
>>
>> Thinking about it, it would also be great to be able to try opcodes  
>> and
>> create signal paths without the need to define an instrument! Mhhhh  
>> not sure
>> how that would work but there may be a logical way of implementing  
>> it???
>>
>> P
>>
>> On 8 Jul 2010, at 14:28, Michael Gogins wrote:
>>
>>> I don't do live coding, but I am interested in it. Anything that
>>> reduces the amount of time between conception and hearing in  
>>> computer
>>> music appeals to me. The faster things go, the more sounds you can
>>> explore.
>>>
>>> So, although I don't do live coding, I have done a great deal of  
>>> work
>>> to make my own composing environment more efficient:
>>>
>>> -- I have a standard "template" script with built-in options for
>>> testing the Csound orchestra, rendering in real-time, or rendering  
>>> to
>>> soundfile.
>>>
>>> -- I have a standard Csound orchestra that actually contains all my
>>> interesting instruments, patched into a signal flow graph with
>>> mastering effects. I just re-arrange the instruments to suit the  
>>> needs
>>> of each piece. The instruments all use the same pfields and are
>>> normalized in loudness.
>>>
>>> -- When rendering to soundfile, the template automatically rescales
>>> the output, creates an MP3, and writes tags, then opens the master
>>> soundfile in a player. This means when the piece sounds good to  
>>> me, it
>>> is actually finished, and I can just upload the MP3 or burn a CD.
>>>
>>> As a result, I can work pretty rapidly, generating dozens of  
>>> pieces in
>>> a working session.
>>>
>>> The main hangup in this setup is that my pieces generally are too
>>> dense to render in real time, so I have to twiddle my thumbs while  
>>> the
>>> pieces render, normalize, etc. But the next computer I get will be  
>>> at
>>> least quad core and the disk will be faster, too.
>>>
>>> Which reminds me -- when is the ParCS branch going to be merged?
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> On Thu, Jul 8, 2010 at 7:49 AM, Peiman Khosravi
>>>  wrote:
>>>>
>>>> Yes of course it was a generalisation :-)
>>>>
>>>> My point was that I don't see the point of live-coding because I  
>>>> don't
>>>> find
>>>> it musically interesting to watch someone write code (or possibly  
>>>> check
>>>> their email!). Why not write the code in the studio and render it
>>>> beforehand? Of course live-coded pieces may be interesting or even
>>>> amazing
>>>> (even if they rarely are), but that has nothing to do with the  
>>>> fact that
>>>> they were live-coded. Live-coding as a paradigm is flawed as far  
>>>> as I am
>>>> concerned. For a start what's the point of seeing a bunch of  
>>>> random lines
>>>> on
>>>> the screen if you don't understand the language?
>>>>
>>>> Of course it would be nice to be able to build signal path in  
>>>> real-time
>>>> with
>>>> csound. But for me it isn't a great disadvantage not to have  
>>>> that, and I
>>>> certainly don't think Csound will die because of it!
>>>>
>>>> P
>>>>
>>>> On 7 Jul 2010, at 18:41, thorin kerr wrote:
>>>>
>>>>> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>>>>>  wrote:
>>>>>
>>>>>> Live-coded
>>>>>> pieces always sound more dead than some of the oldest Music-N  
>>>>>> pieces
>>>>>> (Stria
>>>>>> for instance)!
>>>>>
>>>>> I think this is a bit of a generalisation...
>>>>>
>>>>> One of the first live coded pieces I came across is also one of  
>>>>> the
>>>>> most 'alive' sounding works I know. You can see it here:
>>>>> http://vimeo.com/groups/impromptu/videos/2433947
>>>>>
>>>>> I wouldn't have believed it was live coded unless I saw it  
>>>>> performed
>>>>> with my own eyes. Of course, this is 'algorithmic' live coding  
>>>>> using
>>>>> Impromptu (which can easily use Csound as a synth via OSC, and  
>>>>> could
>>>>> probably use the API as well). I can imagine watching someone  
>>>>> going to
>>>>> great efforts to live-code an FM algorithm might be tedious to  
>>>>> watch.
>>>>>
>>>>> Tk
>>>>>
>>>>>
>>>>> 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"
>>>
>>
>>
>>
>> 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"
>



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 guess it could be a global variable that you set from another instrument?

On 8 July 2010 15:46, Peiman Khosravi  wrote:
> Nice one, thanks!!
>
> Where do you define the value of myflag?
>
> P
>
> On 8 Jul 2010, at 15:42, Michael Gogins wrote:
>
>> You can generate score events from inside instruments. You can also
>> schedule an instrument instance to be always on.
>>
>> You would, however, have to do something to guard against endless
>> recursion. Something like this:
>>
>> alwayson myinstrument ... 1
>>
>> instr myinstrument
>> if myflag == 1 then
>> schedule "myinstrument", ...,0
>> endif
>> ;make some noise
>> endin
>>
>> Regards,
>> Mike
>>
>> On Thu, Jul 8, 2010 at 9:38 AM, Peiman Khosravi
>>  wrote:
>>>
>>> Interestingly, I have a friend who composes only with SC3. Including
>>> mixing
>>> and everything. As his projects get larger and denser he runs out of
>>> processing power and has to move to protools to mix the layers together.
>>>
>>> And apparently it is more hassle to use SC3 in non-real-time than in
>>> real-time (I don't know if this is true as I've never used SC3 in
>>> non-real-time mode).
>>>
>>> The one things that does slow down the work-flaw in csound for me is the
>>> need to define a score event for every instrument. It would indeed be
>>> nice
>>> to be able to write an instrument and include some sort of 'play' command
>>> inside the instrument that starts performance indefinitely. Eliminating
>>> the
>>> need to have a score section all together.
>>>
>>> Thinking about it, it would also be great to be able to try opcodes and
>>> create signal paths without the need to define an instrument! Mhhhh not
>>> sure
>>> how that would work but there may be a logical way of implementing it???
>>>
>>> P
>>>
>>> On 8 Jul 2010, at 14:28, Michael Gogins wrote:
>>>
>>>> I don't do live coding, but I am interested in it. Anything that
>>>> reduces the amount of time between conception and hearing in computer
>>>> music appeals to me. The faster things go, the more sounds you can
>>>> explore.
>>>>
>>>> So, although I don't do live coding, I have done a great deal of work
>>>> to make my own composing environment more efficient:
>>>>
>>>> -- I have a standard "template" script with built-in options for
>>>> testing the Csound orchestra, rendering in real-time, or rendering to
>>>> soundfile.
>>>>
>>>> -- I have a standard Csound orchestra that actually contains all my
>>>> interesting instruments, patched into a signal flow graph with
>>>> mastering effects. I just re-arrange the instruments to suit the needs
>>>> of each piece. The instruments all use the same pfields and are
>>>> normalized in loudness.
>>>>
>>>> -- When rendering to soundfile, the template automatically rescales
>>>> the output, creates an MP3, and writes tags, then opens the master
>>>> soundfile in a player. This means when the piece sounds good to me, it
>>>> is actually finished, and I can just upload the MP3 or burn a CD.
>>>>
>>>> As a result, I can work pretty rapidly, generating dozens of pieces in
>>>> a working session.
>>>>
>>>> The main hangup in this setup is that my pieces generally are too
>>>> dense to render in real time, so I have to twiddle my thumbs while the
>>>> pieces render, normalize, etc. But the next computer I get will be at
>>>> least quad core and the disk will be faster, too.
>>>>
>>>> Which reminds me -- when is the ParCS branch going to be merged?
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>> On Thu, Jul 8, 2010 at 7:49 AM, Peiman Khosravi
>>>>  wrote:
>>>>>
>>>>> Yes of course it was a generalisation :-)
>>>>>
>>>>> My point was that I don't see the point of live-coding because I don't
>>>>> find
>>>>> it musically interesting to watch someone write code (or possibly check
>>>>> their email!). Why not write the code in the studio and render it
>>>>> beforehand? Of course live-coded pieces may be interesting or even
>>>>> amazing
>>>>> (even if they rarely are), but that has nothing to do with the fact
>>>>> that
>>>>> they were live-coded. Live-coding as a paradigm is flawed as far as I
>>>>> am
>>>>> concerned. For a start what's the point of seeing a bunch of random
>>>>> lines
>>>>> on
>>>>> the screen if you don't understand the language?
>>>>>
>>>>> Of course it would be nice to be able to build signal path in real-time
>>>>> with
>>>>> csound. But for me it isn't a great disadvantage not to have that, and
>>>>> I
>>>>> certainly don't think Csound will die because of it!
>>>>>
>>>>> P
>>>>>
>>>>> On 7 Jul 2010, at 18:41, thorin kerr wrote:
>>>>>
>>>>>> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>>>>>>  wrote:
>>>>>>
>>>>>>> Live-coded
>>>>>>> pieces always sound more dead than some of the oldest Music-N pieces
>>>>>>> (Stria
>>>>>>> for instance)!
>>>>>>
>>>>>> I think this is a bit of a generalisation...
>>>>>>
>>>>>> One of the first live coded pieces I came across is also one of the
>>>>>> most 'alive' sounding works I know. You can see it here:
>>>>>> http://vimeo.com/groups/impromptu/videos/2433947
>>>>>>
>>>>>> I wouldn't have believed it was live coded unless I saw it performed
>>>>>> with my own eyes. Of course, this is 'algorithmic' live coding using
>>>>>> Impromptu (which can easily use Csound as a synth via OSC, and could
>>>>>> probably use the API as well). I can imagine watching someone going to
>>>>>> great efforts to live-code an FM algorithm might be tedious to watch.
>>>>>>
>>>>>> Tk
>>>>>>
>>>>>>
>>>>>> 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"
>>>>
>>>
>>>
>>>
>>> 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"
>>
>
>
>
> 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"

Still this is a lot more hassle than something like this:

instr 1

;make some noise


	playnote

endin

Also it would be great if all the opcodes that require a table  
definition had an internally created default table if a table is  
defined as 'default' or something.

P


On 8 Jul 2010, at 15:42, Michael Gogins wrote:

> You can generate score events from inside instruments. You can also
> schedule an instrument instance to be always on.
>
> You would, however, have to do something to guard against endless
> recursion. Something like this:
>
> alwayson myinstrument ... 1
>
> instr myinstrument
> if myflag == 1 then
> schedule "myinstrument", ...,0
> endif
> ;make some noise
> endin
>
> Regards,
> Mike
>
> On Thu, Jul 8, 2010 at 9:38 AM, Peiman Khosravi
>  wrote:
>> Interestingly, I have a friend who composes only with SC3.  
>> Including mixing
>> and everything. As his projects get larger and denser he runs out of
>> processing power and has to move to protools to mix the layers  
>> together.
>>
>> And apparently it is more hassle to use SC3 in non-real-time than in
>> real-time (I don't know if this is true as I've never used SC3 in
>> non-real-time mode).
>>
>> The one things that does slow down the work-flaw in csound for me  
>> is the
>> need to define a score event for every instrument. It would indeed  
>> be nice
>> to be able to write an instrument and include some sort of 'play'  
>> command
>> inside the instrument that starts performance indefinitely.  
>> Eliminating the
>> need to have a score section all together.
>>
>> Thinking about it, it would also be great to be able to try opcodes  
>> and
>> create signal paths without the need to define an instrument! Mhhhh  
>> not sure
>> how that would work but there may be a logical way of implementing  
>> it???
>>
>> P
>>
>> On 8 Jul 2010, at 14:28, Michael Gogins wrote:
>>
>>> I don't do live coding, but I am interested in it. Anything that
>>> reduces the amount of time between conception and hearing in  
>>> computer
>>> music appeals to me. The faster things go, the more sounds you can
>>> explore.
>>>
>>> So, although I don't do live coding, I have done a great deal of  
>>> work
>>> to make my own composing environment more efficient:
>>>
>>> -- I have a standard "template" script with built-in options for
>>> testing the Csound orchestra, rendering in real-time, or rendering  
>>> to
>>> soundfile.
>>>
>>> -- I have a standard Csound orchestra that actually contains all my
>>> interesting instruments, patched into a signal flow graph with
>>> mastering effects. I just re-arrange the instruments to suit the  
>>> needs
>>> of each piece. The instruments all use the same pfields and are
>>> normalized in loudness.
>>>
>>> -- When rendering to soundfile, the template automatically rescales
>>> the output, creates an MP3, and writes tags, then opens the master
>>> soundfile in a player. This means when the piece sounds good to  
>>> me, it
>>> is actually finished, and I can just upload the MP3 or burn a CD.
>>>
>>> As a result, I can work pretty rapidly, generating dozens of  
>>> pieces in
>>> a working session.
>>>
>>> The main hangup in this setup is that my pieces generally are too
>>> dense to render in real time, so I have to twiddle my thumbs while  
>>> the
>>> pieces render, normalize, etc. But the next computer I get will be  
>>> at
>>> least quad core and the disk will be faster, too.
>>>
>>> Which reminds me -- when is the ParCS branch going to be merged?
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> On Thu, Jul 8, 2010 at 7:49 AM, Peiman Khosravi
>>>  wrote:
>>>>
>>>> Yes of course it was a generalisation :-)
>>>>
>>>> My point was that I don't see the point of live-coding because I  
>>>> don't
>>>> find
>>>> it musically interesting to watch someone write code (or possibly  
>>>> check
>>>> their email!). Why not write the code in the studio and render it
>>>> beforehand? Of course live-coded pieces may be interesting or even
>>>> amazing
>>>> (even if they rarely are), but that has nothing to do with the  
>>>> fact that
>>>> they were live-coded. Live-coding as a paradigm is flawed as far  
>>>> as I am
>>>> concerned. For a start what's the point of seeing a bunch of  
>>>> random lines
>>>> on
>>>> the screen if you don't understand the language?
>>>>
>>>> Of course it would be nice to be able to build signal path in  
>>>> real-time
>>>> with
>>>> csound. But for me it isn't a great disadvantage not to have  
>>>> that, and I
>>>> certainly don't think Csound will die because of it!
>>>>
>>>> P
>>>>
>>>> On 7 Jul 2010, at 18:41, thorin kerr wrote:
>>>>
>>>>> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>>>>>  wrote:
>>>>>
>>>>>> Live-coded
>>>>>> pieces always sound more dead than some of the oldest Music-N  
>>>>>> pieces
>>>>>> (Stria
>>>>>> for instance)!
>>>>>
>>>>> I think this is a bit of a generalisation...
>>>>>
>>>>> One of the first live coded pieces I came across is also one of  
>>>>> the
>>>>> most 'alive' sounding works I know. You can see it here:
>>>>> http://vimeo.com/groups/impromptu/videos/2433947
>>>>>
>>>>> I wouldn't have believed it was live coded unless I saw it  
>>>>> performed
>>>>> with my own eyes. Of course, this is 'algorithmic' live coding  
>>>>> using
>>>>> Impromptu (which can easily use Csound as a synth via OSC, and  
>>>>> could
>>>>> probably use the API as well). I can imagine watching someone  
>>>>> going to
>>>>> great efforts to live-code an FM algorithm might be tedious to  
>>>>> watch.
>>>>>
>>>>> Tk
>>>>>
>>>>>
>>>>> 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"
>>>
>>
>>
>>
>> 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"
>



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"

or better even:

	playnote ktrig

P


On 8 Jul 2010, at 16:06, Peiman Khosravi wrote:

> Still this is a lot more hassle than something like this:
>
> instr 1
>
> ;make some noise
>
>
> 	playnote
>
> endin
>
> Also it would be great if all the opcodes that require a table  
> definition had an internally created default table if a table is  
> defined as 'default' or something.
>
> P
>
>
> On 8 Jul 2010, at 15:42, Michael Gogins wrote:
>
>> You can generate score events from inside instruments. You can also
>> schedule an instrument instance to be always on.
>>
>> You would, however, have to do something to guard against endless
>> recursion. Something like this:
>>
>> alwayson myinstrument ... 1
>>
>> instr myinstrument
>> if myflag == 1 then
>> schedule "myinstrument", ...,0
>> endif
>> ;make some noise
>> endin
>>
>> Regards,
>> Mike
>>
>> On Thu, Jul 8, 2010 at 9:38 AM, Peiman Khosravi
>>  wrote:
>>> Interestingly, I have a friend who composes only with SC3.  
>>> Including mixing
>>> and everything. As his projects get larger and denser he runs out of
>>> processing power and has to move to protools to mix the layers  
>>> together.
>>>
>>> And apparently it is more hassle to use SC3 in non-real-time than in
>>> real-time (I don't know if this is true as I've never used SC3 in
>>> non-real-time mode).
>>>
>>> The one things that does slow down the work-flaw in csound for me  
>>> is the
>>> need to define a score event for every instrument. It would indeed  
>>> be nice
>>> to be able to write an instrument and include some sort of 'play'  
>>> command
>>> inside the instrument that starts performance indefinitely.  
>>> Eliminating the
>>> need to have a score section all together.
>>>
>>> Thinking about it, it would also be great to be able to try  
>>> opcodes and
>>> create signal paths without the need to define an instrument!  
>>> Mhhhh not sure
>>> how that would work but there may be a logical way of implementing  
>>> it???
>>>
>>> P
>>>
>>> On 8 Jul 2010, at 14:28, Michael Gogins wrote:
>>>
>>>> I don't do live coding, but I am interested in it. Anything that
>>>> reduces the amount of time between conception and hearing in  
>>>> computer
>>>> music appeals to me. The faster things go, the more sounds you can
>>>> explore.
>>>>
>>>> So, although I don't do live coding, I have done a great deal of  
>>>> work
>>>> to make my own composing environment more efficient:
>>>>
>>>> -- I have a standard "template" script with built-in options for
>>>> testing the Csound orchestra, rendering in real-time, or  
>>>> rendering to
>>>> soundfile.
>>>>
>>>> -- I have a standard Csound orchestra that actually contains all my
>>>> interesting instruments, patched into a signal flow graph with
>>>> mastering effects. I just re-arrange the instruments to suit the  
>>>> needs
>>>> of each piece. The instruments all use the same pfields and are
>>>> normalized in loudness.
>>>>
>>>> -- When rendering to soundfile, the template automatically rescales
>>>> the output, creates an MP3, and writes tags, then opens the master
>>>> soundfile in a player. This means when the piece sounds good to  
>>>> me, it
>>>> is actually finished, and I can just upload the MP3 or burn a CD.
>>>>
>>>> As a result, I can work pretty rapidly, generating dozens of  
>>>> pieces in
>>>> a working session.
>>>>
>>>> The main hangup in this setup is that my pieces generally are too
>>>> dense to render in real time, so I have to twiddle my thumbs  
>>>> while the
>>>> pieces render, normalize, etc. But the next computer I get will  
>>>> be at
>>>> least quad core and the disk will be faster, too.
>>>>
>>>> Which reminds me -- when is the ParCS branch going to be merged?
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>> On Thu, Jul 8, 2010 at 7:49 AM, Peiman Khosravi
>>>>  wrote:
>>>>>
>>>>> Yes of course it was a generalisation :-)
>>>>>
>>>>> My point was that I don't see the point of live-coding because I  
>>>>> don't
>>>>> find
>>>>> it musically interesting to watch someone write code (or  
>>>>> possibly check
>>>>> their email!). Why not write the code in the studio and render it
>>>>> beforehand? Of course live-coded pieces may be interesting or even
>>>>> amazing
>>>>> (even if they rarely are), but that has nothing to do with the  
>>>>> fact that
>>>>> they were live-coded. Live-coding as a paradigm is flawed as far  
>>>>> as I am
>>>>> concerned. For a start what's the point of seeing a bunch of  
>>>>> random lines
>>>>> on
>>>>> the screen if you don't understand the language?
>>>>>
>>>>> Of course it would be nice to be able to build signal path in  
>>>>> real-time
>>>>> with
>>>>> csound. But for me it isn't a great disadvantage not to have  
>>>>> that, and I
>>>>> certainly don't think Csound will die because of it!
>>>>>
>>>>> P
>>>>>
>>>>> On 7 Jul 2010, at 18:41, thorin kerr wrote:
>>>>>
>>>>>> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>>>>>>  wrote:
>>>>>>
>>>>>>> Live-coded
>>>>>>> pieces always sound more dead than some of the oldest Music-N  
>>>>>>> pieces
>>>>>>> (Stria
>>>>>>> for instance)!
>>>>>>
>>>>>> I think this is a bit of a generalisation...
>>>>>>
>>>>>> One of the first live coded pieces I came across is also one of  
>>>>>> the
>>>>>> most 'alive' sounding works I know. You can see it here:
>>>>>> http://vimeo.com/groups/impromptu/videos/2433947
>>>>>>
>>>>>> I wouldn't have believed it was live coded unless I saw it  
>>>>>> performed
>>>>>> with my own eyes. Of course, this is 'algorithmic' live coding  
>>>>>> using
>>>>>> Impromptu (which can easily use Csound as a synth via OSC, and  
>>>>>> could
>>>>>> probably use the API as well). I can imagine watching someone  
>>>>>> going to
>>>>>> great efforts to live-code an FM algorithm might be tedious to  
>>>>>> watch.
>>>>>>
>>>>>> Tk
>>>>>>
>>>>>>
>>>>>> 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"
>>>>
>>>
>>>
>>>
>>> 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"
>>
>



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"

Well... it might be worthwhile considering live-coding in two ways.
You can use a live-coding environment (Chuck, SC etc...) for
composing, which may or may not suit your compositional approach.

And then there's live-coding as a performance practice. I don't want
to appear too much of a live-coding advocate, but I think it's worth
pointing out that live coding - as a performance practice - has grown
in popularity in part to counter the boring presentation of laptop
performances.

For those who want to explore it more, the online congregation point
for live-coders seems to be here at the moment:
http://www.toplap.org/

That being said, I do think audience non-comprehension is a real
issue. There are some arguments about this (such as "I don't play
guitar, but I can appreciate a guitar player"), but coding in front of
others isn't quite the same thing thing as playing a guitar.

However, I've live-coded a few times (using csound and Impromptu, and
on one occasion emacs, python and csound) and projected my code: My
experience has been that you do get a real engagement from the
audience. They watch the code, they watch your face, they watch your
fingers, they smile a little, and they watch the code again. That felt
like a performance.

Thorin












On Thu, Jul 8, 2010 at 9:49 PM, Peiman Khosravi
 wrote:
> Yes of course it was a generalisation :-)
>
> My point was that I don't see the point of live-coding because I don't find
> it musically interesting to watch someone write code (or possibly check
> their email!). Why not write the code in the studio and render it
> beforehand? Of course live-coded pieces may be interesting or even amazing
> (even if they rarely are), but that has nothing to do with the fact that
> they were live-coded. Live-coding as a paradigm is flawed as far as I am
> concerned. For a start what's the point of seeing a bunch of random lines on
> the screen if you don't understand the language?
>
> Of course it would be nice to be able to build signal path in real-time with
> csound. But for me it isn't a great disadvantage not to have that, and I
> certainly don't think Csound will die because of it!
>
> P
>
> On 7 Jul 2010, at 18:41, thorin kerr wrote:
>
>> On Thu, Jul 8, 2010 at 3:14 AM, Peiman Khosravi
>>  wrote:
>>
>>> Live-coded
>>> pieces always sound more dead than some of the oldest Music-N pieces
>>> (Stria
>>> for instance)!
>>
>> I think this is a bit of a generalisation...
>>
>> One of the first live coded pieces I came across is also one of the
>> most 'alive' sounding works I know. You can see it here:
>> http://vimeo.com/groups/impromptu/videos/2433947
>>
>> I wouldn't have believed it was live coded unless I saw it performed
>> with my own eyes. Of course, this is 'algorithmic' live coding using
>> Impromptu (which can easily use Csound as a synth via OSC, and could
>> probably use the API as well). I can imagine watching someone going to
>> great efforts to live-code an FM algorithm might be tedious to watch.
>>
>> Tk
>>
>>
>> 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"
>
>


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. From a quick look, it seems you can't really define synths in
python, but only turn them on (so you can basically do the same from
python fro Csound and SC...). Am I missing something?

Cheers,
Andrés

On Thu, Jul 8, 2010 at 1:46 PM, Bernardo Barros
 wrote:
> 2010/7/8 Andres Cabrera :
>> Hi,
>>
>> Do you have a link to controlling scsynth from python?
>>
>
> http://pypi.python.org/pypi/SC/0.2
>
> (but sclang is also very good :-)
>
>
> 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"

That's true.  Nobody did that yet. Someone made a Rudy interface to
control SC, that one can make SynthDefs.  But I don't know... SCLang
is really nice, and has a lot in common with Python. If you are not a
experient Python or Ruby programmer I don't see a strong reason to
control SCSynth from another language.


2010/7/9, Andres Cabrera :
> Thanks. From a quick look, it seems you can't really define synths in
> python, but only turn them on (so you can basically do the same from
> python fro Csound and SC...). Am I missing something?
>
> Cheers,
> Andrés
>
> On Thu, Jul 8, 2010 at 1:46 PM, Bernardo Barros
>  wrote:
>> 2010/7/8 Andres Cabrera :
>>> Hi,
>>>
>>> Do you have a link to controlling scsynth from python?
>>>
>>
>> http://pypi.python.org/pypi/SC/0.2
>>
>> (but sclang is also very good :-)
>>
>>
>> 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"
>
>


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"

This thread has wandered from its original topic, live coding in
Python, to the need for a parallel version of Csound.

Regards,
Mike

On Fri, Jul 9, 2010 at 2:37 PM, Bernardo Barros
 wrote:
> That's true.  Nobody did that yet. Someone made a Rudy interface to
> control SC, that one can make SynthDefs.  But I don't know... SCLang
> is really nice, and has a lot in common with Python. If you are not a
> experient Python or Ruby programmer I don't see a strong reason to
> control SCSynth from another language.
>
>
> 2010/7/9, Andres Cabrera :
>> Thanks. From a quick look, it seems you can't really define synths in
>> python, but only turn them on (so you can basically do the same from
>> python fro Csound and SC...). Am I missing something?
>>
>> Cheers,
>> Andrés
>>
>> On Thu, Jul 8, 2010 at 1:46 PM, Bernardo Barros
>>  wrote:
>>> 2010/7/8 Andres Cabrera :
>>>> Hi,
>>>>
>>>> Do you have a link to controlling scsynth from python?
>>>>
>>>
>>> http://pypi.python.org/pypi/SC/0.2
>>>
>>> (but sclang is also very good :-)
>>>
>>>
>>> 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"
>>
>>
>
>
> 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"