http://www.nabble.com/file/p17044773/tryagain.zip tryagain.zip 

So linked above is yet another poorly understood hack from the same 2
examples of the csound api (cb.py & wxController.py) that represents the
model of the process i'm trying to design.

I want to 

1) watch the csound thread for MIDI input data

2) use the cb.py callback() method (or similar) to trigger the Python based
compilation of 

performanceThread.InputMessage(s)

where s is the compiled score statement from the requested callback()

Ultimately, there will be a concurrent wx interface, which is why i'm trying
to use the basic "threading" model of the wxController.py example (although
for simplicity i have here abandoned any wx interface elements)

I've spent most of the last few days simply sketching out Class & GUI
designs for my "bigger picture" & getting ready for my final assault.

But despite entertaining various options for simplifying the implementation
strategy of my designs, sooner or later it appears I need to use Python to
compile score statements in realtime, & fire them at the CSD.

If only there was a way to return a string variable to csound via pyops (?)

i could then use a conditional trigger of the scoreline opcode, attach to it
the returned string variable, & that might suffice.

As it is, can't somebody start to see (other than Oeyvind) where i am going
with this, & the fact that the basic mechanism i am trying to model here
could potentially underly just about ANY real-time based, python / csound
hybrid development? (ie use Csound to gather real time input, & python to
configure sco statements for ultimate delivery of audio, assumedly (for
ease) via callback to the same, original, csound thread?)

I believe a basic model of this approach could be illustrated in less than a
couple of hundered lines of code (as my efforts to date have tried to
suggest) & intend to push & push until this process is clarified &
understood.

As the examples, after all, remain the only viable inroad to understanding
the API, it seems only fair to want to implement this one, as a basis for my
own future work, & the benefit of other bemused onlookers now & in the
future.

I will never surrender

Tim



-----
*******************
www.phasetransitions.net
hermetic music * python * csound * possibly mindless ranting
various werk in perpetual delusions of progress....

-- 
View this message in context: http://www.nabble.com/try-again-tp17044773p17044773.html
Sent from the Csound - General mailing list archive at Nabble.com.

Otherwise tell me when all your summer holidays arrive & i'll repost my API
queries then.



Tim Mortimer wrote:
> 
>  http://www.nabble.com/file/p17044773/tryagain.zip tryagain.zip 
> 
> So linked above is yet another poorly understood hack from the same 2
> examples of the csound api (cb.py & wxController.py) that represents the
> model of the process i'm trying to design.
> 
> I want to 
> 
> 1) watch the csound thread for MIDI input data
> 
> 2) use the cb.py callback() method (or similar) to trigger the Python
> based compilation of 
> 
> performanceThread.InputMessage(s)
> 
> where s is the compiled score statement from the requested callback()
> 
> Ultimately, there will be a concurrent wx interface, which is why i'm
> trying to use the basic "threading" model of the wxController.py example
> (although for simplicity i have here abandoned any wx interface elements)
> 
> I've spent most of the last few days simply sketching out Class & GUI
> designs for my "bigger picture" & getting ready for my final assault.
> 
> But despite entertaining various options for simplifying the
> implementation strategy of my designs, sooner or later it appears I need
> to use Python to compile score statements in realtime, & fire them at the
> CSD.
> 
> If only there was a way to return a string variable to csound via pyops
> (?)
> 
> i could then use a conditional trigger of the scoreline opcode, attach to
> it the returned string variable, & that might suffice.
> 
> As it is, can't somebody start to see (other than Oeyvind) where i am
> going with this, & the fact that the basic mechanism i am trying to model
> here could potentially underly just about ANY real-time based, python /
> csound hybrid development? (ie use Csound to gather real time input, &
> python to configure sco statements for ultimate delivery of audio,
> assumedly (for ease) via callback to the same, original, csound thread?)
> 
> I believe a basic model of this approach could be illustrated in less than
> a couple of hundered lines of code (as my efforts to date have tried to
> suggest) & intend to push & push until this process is clarified &
> understood.
> 
> As the examples, after all, remain the only viable inroad to understanding
> the API, it seems only fair to want to implement this one, as a basis for
> my own future work, & the benefit of other bemused onlookers now & in the
> future.
> 
> I will never surrender
> 
> Tim
> 
> 
> 


-----
*******************
www.phasetransitions.net
hermetic music * python * csound * possibly mindless ranting
various werk in perpetual delusions of progress....

-- 
View this message in context: http://www.nabble.com/try-again-tp17044773p17052781.html
Sent from the Csound - General mailing list archive at Nabble.com.