|
I've worked my way through cb.py & wxController.py in the examples directory
& i'm starting to feel (after several months of random headbutting attempts)
that i'm getting just a vague hint of what is actually going on with all
this.
http://www.nabble.com/file/p16930347/MIDI%2Bto%2BCS%2Bto%2BPy%2Bbact%2B2%2BCS.zip
MIDI+to+CS+to+Py+bact+2+CS.zip
The attached / uploaded to Nabble & linked code runs, but i'd recommend
running from the command line, where a double execution of c will
terminate csound & then python (in turn apparently, very neat...).
it's a sort of hack of cb.py.
MIDI goes in to csound, & data is assigned using chnexport to & fro python.
there is no wxInterface component of any description yet - i would like to
insert one into this example, however im not sure to what extent the whole
>>>
import time
time.sleep()
>>>
approach victor demonstrates with his callbacks is compatible with the
>>>
import threading
self.performanceThread = csnd.CsoundPerformanceThread(self.csound)
self.performanceThread.Play()
>>>
strategy adopted in the wxController.py example.
#####
The 2 examples I'm drawing from is a CLASSIC example of why learning from
examples with this is extremely difficult.
One example (Victors cb.py) uses csnd.Csound() as opposed to the
wxController.py example that utilises csnd.CppSound() - so how am i (the
casual interested onlooker) meant to deduce exactly how it all fits
together? (if you see what i mean...)
(notwithstanding of course that i am extremely greatful any of this exists
in the first place)
#####
the short little real-time MIDI transposition i have taking place is
essentially synonymous for the whole interactive atomic database i have in
mind. It will make conditional returns using pfield statements &
InputMessage() to the csd, as well as utilising some concurrent
csound.SetChannel() methods as per Victor's / my amended demonstration
my only concern is that this simple mockup was wavering between 2% & 8% on
my cpu, & that seems as though by the time i add some decent tone colours, &
a wx interface, more channel calls & start assembilng string variables to
fire off as score statements using
>>> InputMessage()
to & fro that this could blow out quite quickly.
plan b would be to simply write the database front end anyway, & dump the
database to a large series of ftables in csound & run the whole mechanics of
the thing purely from csound - strip the real time interface back to simply
editing the parameters of the sounds & creating snapshots....(albeit to be
add back into & used in the database...)
or a combination approach with limited passes from the interface of simply
controlID, value, & an associated target ftable index perhaps to allocate
all values to ftables for "in csound" reference & execution.
but if it can work - handling & storing the database in python with real
time dispensability to a csound orchestra has to be the number 1 choice i
would think....
please help me bring this illustrative prototype together. it doesnt have to
be big, or clever, but if it could demonstrate how to collate & compile
pfield score statements on the fly from Python based datasets & allow
defining 1 or 2 of the database values from a gui (& maybe a token volume
control or something as a parralell process) it will be hopefully a great
launch pad for my ambitions, & useful real time application template for
future use as an example...
-----
*******************
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/API-queries---some-example-code-i%27ve-thrown-together-tp16930347p16930347.html
Sent from the Csound - General mailing list archive at Nabble.com.
|