Could you please explain more completely what you are trying to do in musical terms, not software engineering terms?

Regards,
Mike

-----Original Message-----
>From: Tim Mortimer 
>Sent: May 4, 2008 8:01 PM
>To: csound@lists.bath.ac.uk
>Subject: [Csnd] Re: try again
>
>
>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.
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks Michael.

I want to create in python a database of elements that define musical
"patterns" or gestures. (think Feldman & pitch classes, particularly String
Quartet #2, the late piano & multi-piano works etc...)

Patterns are essentially assembies of octivated PC sets, in defined orders,
but without rhythmic information.

I want the capacity to step through patterns by driving them "step by step"
in real time, with real time midi note triggers. 

I can then record series of rhythmic variations for those Patterns, &
explore combinations & sequences of those Patterns.

Patterns united with these Rhythms will create "Gestures".

Gestures are quilted together to make 6 hr sprawling megaliths of
spectrallly altered wallpaper.

Duration values in the Pattern definition are conditional. Ties,
terminations, & polyphony issues can all be use to resolved held notes in
real time, & patterns can be thus be arbitrarily knitted together in any
variation of simultenaeity or sequential order, & the performance realised
in realtime, & an output score of the "musical sketch" written accordingly. 

Ditto "Gestures" recorded to the database (i.e. the acknowledged / recorded
combinations of Patterns & Rhythms)

because rhythm, instrumentation, durational conditions, order, octivation,
pitch, & even "pattern shape" are defined as "atomic elements" of my Pattern
Class, this encourages a "democratisation" of these elements vis a vis
creating pattern "variations"

i copy a pattern, i change its instrumentation

i copy it again,. i change its octivation

i copy it again, i change its order

there is no sequencing aspect to this stage of the composition.

By reverse, compositions can become "self analyzing", & the pattern database
can be explored for hitherto unrecognised simultenaeities / thematic
similarities & futher variation explored on that basis...

every pattern carries its inherant instructions as to what to do when
greeted with the next pattern.

eventually when all the patterns are linked to all the rhythms in various
combinations, the same real time midi input system could be used to "drive"
whole "systems" in arbitrary / improvised arrangement ideas.

is this starting to give you a sense of what i am trying to do?

If you want further insight into my exact methodology, i have an open office
spreadsheet & oodles of existing Python & Csound code proving the basic
design elements are at  least a functional possibility. 

Parseval is, in part, a non - real time exploration of some of these ideas

However i'd suggest the sensible thing to do is "trust me", & help me knock
up some sort of real time / threading / interface & API working model. ; )

The compositional model is unproven, however its seems a shed load more
interesting to me than any creative alternatives i'd otherwise be
considering at the moment.

It offers a way to combine the arbitrariness & wilful aspects of "regular"
composition, with an aid to that process in the language & formal tools of
algorithmic composition - & in doing so open up the potential stochastic /
algorithmic input into the process as well...

Basically think microsoft access with a MIDI backend, a csound front end, &
the capacity to use a Grid or similar to sketch out the "shape" of the
Musical "Patterns" (the open office document i have created illustrates
this, but i'd have to write a short commentary on it if you wanted to
examine it)

err, any clearer? suggestions or comments? (& i really better get back to
keying my bosses tax receipts now...)






-----
*******************
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-tp17044773p17053728.html
Sent from the Csound - General mailing list archive at Nabble.com.

there is of course, more to it than this, but you get the picture.

Is there a text or a resource i could be looking at to improve my
comprehension of the existing api refman?

Certain methods are obviously only used in combination with other methods,
but there might be more than one "method strategy" to achieve the basic
desired outcome. (eg - achieving callbacks  & sending score messages to
csound as a functional & cohesive "model" for example... & coincidentally
the one i am trying to develop (with a wxInterface..)...)

Failure to understand this seems to me to the biggest obstacle to utilising
the API.

That & some simple explanation of what the functions are, what they return,
what the inputs are, that sort of thing.

After all, i don't know C or C++, & if i did i probably wouldn't be
attempting to use the Python API in the first place.

I was even prepared to learn C++ in a linux environment as a "workaround"
heaven forbid - but that angle is presently cut off to me also (possibly a
blessing in disguise...)

Ive even deliberately avoided using API in any of my work to date to try &
simplify the exploration of the issues & theories & methodologies.

But the general signs are i might be on to something of creative worth, so i
now reluctantly face the single remaining barrier to "living the dream" here
- Python to manage the "musical database", csound to access it in realtime &
spit out the appropraite MIDI or audio... & the barrier being simply
understanding the API.

-----
*******************
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-tp17044773p17053901.html
Sent from the Csound - General mailing list archive at Nabble.com.

Heres another attempt to get midi to python to write score events back to
csound in real time.

http://www.nabble.com/file/p17054263/OeyvindStyle.zip OeyvindStyle.zip 

It's based on some references into the heart of improsculpt that oeyvind
sent me over the weekend that, initially, i forgot about.

This doesn't run, but at least it, to my eye, seems like a potentially
elegant & easy to understand solution if i could actually get it to run.

Oeyvind you may consider working some explanatory magic upon this therefore
at some stage?

It may also be easier to get working without the threading. But just to
reiterate i'm threading in anticipation of some wxPython interface
components.

i think a short demonstration of this without threading (& hence no gui
option) might also be of value however. i could work with my "database"
without a GUI after all if i had to, using .txt files to write the content,
& report on database queries simply by writing the reports also to .txt
file.

another monologue of consecutive posts from me. sorry guys. I hope it will
be worth it! But there is a simple, core, demonstrable principle in here i
am confident - a simple doorway to a world of python fuelled realtime & GUI
supporting possibilities...


-----
*******************
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-tp17044773p17054263.html
Sent from the Csound - General mailing list archive at Nabble.com.

Different Day

Different Approach

Same Outcome

http://www.nabble.com/file/p17071574/anothersimplecall.zip
anothersimplecall.zip 

I literally can't do anthing else until i can work out how to get MIDI
triggers from csound to call python methods to activate InputMessages() back
to the csound thread.

What Oeyvind has been able to direct me to so far by way of example in
Improsculpt, i have been able to absorb & understand.

Without mimicing the complete core infrastructure of ImproSculpt (something
i feel is probably excessive to my experimentally led development at this
stage), & in deference to the idea of creating a very simple example (in the
spirit of existing API.py examples) i really can only continue to make pleas
for assistance.

the zips i have been sending links to contain on average probably 50 - 60 of
actual functional lines of code.

I cannot make the problem any simpler.

If someone can make the sequence of events run & work, with or without a wx
thread, that would be just freaking awesome.

all one would need to do in the present example is replace the python "print
a" statement in the midiNoteInput() function with a InputMessage("blah blah
blah") statement 

But the CSD doesnt really seem to get up & running in this version....


-----
*******************
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-tp17044773p17071574.html
Sent from the Csound - General mailing list archive at Nabble.com.

Oeyvind you are a true champion.

I was combing over your "bare bones" app this afternoon looking for more
clues - this is definately a slow but important step forward.

Your code runs from my command line on windows, but exits with some error
messages.

The code doesn't run when i launch it from within scite. There are some
apparently related error messages spat out there too, but a different
overall "failure" scenario

i have attached (via nabble link) a printout of the errors.

http://www.nabble.com/file/p17078738/simplecalledit%2Berrors.zip
simplecalledit+errors.zip 

My wx is still pretty iffy. maybe that is the source of the error (Michael's
wx example employs some slightly different syntactic conventions to that
offered in the book).

In essence, i am presently looking to just open a blank wx window
(obviously), so i know the wx thread is accessible when i finally get around
to wanting it.

The MIDI access to the python elements is the main aspect i'm trying to get
rolling. this is 99% of the way there (the other 1% is me trying to see if i
can get my latency down a bit... time to read that bit of the manual again
(& Jonathan Murphys tutorial spiel about -b & -B - where is Jonathan these
days anyway?))

& seeing if i/ we can't eliminate the exit crash - there is no rush here -
Im working next 2 days & I'm out tomorrow night....

No max, no pd.... just straight up python & csound API for MIDI & AUDIO -
how sweet is that!

I'll prod & poke this for a little while longer this evening & see if i get
any joy.

-----
*******************
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-tp17044773p17078738.html
Sent from the Csound - General mailing list archive at Nabble.com.

hey tim,

have you looked at wxgade?

http://wxglade.sourceforge.net/

It certainly speeds up my dev. turnaround time. cross-platform too :-)

ciao,

D.

Re scite - yes, your probably right - Michael G may have further insights...


Oeyvind Brandtsegg-2 wrote:
> 
> 
> Of course one bad thing about my fix is that I had to resort to the
> old ksmps loop instead of using the performanceThread, but afaik this
> is the only way to allow pycalls.
> 
> 

I think i knew that. My adopting your methodology seems to have 2 basic
advantages 1) it works 2) it will entrench the approach & make it less
likely that something will come along to force a change to it in the future!

The basic model of our apps is similar, but their focus & concerns are quite
different. You've paved the way for people like me here Oeyvind, & until
someone says otherwise i'll do what you have done in terms of achieving a
basic working methodology.

If i can sucessfully cultivate my ideas further based on your model (where
appropriate), the architecture of our "programs" is likely to become more
alike & potential options for interchangeability of functionality & elements
might play into both of our favours...

I have started looking into barebones & improsculpt in more detail. There
seems to be a lot in both that makes sense to me, & with time i hope this is
a trend that continues.

In terms of your "server" structure / GUI vs Csound split - did you at any
stage consider putting the real time midi handling in with the GUI side &
use OSC or PYRO to deliver MIDI to csound also?


-----
*******************
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-tp17044773p17079384.html
Sent from the Csound - General mailing list archive at Nabble.com.