Re: [Cs-dev] remove csoundPreCompile

Date	2012-04-30 14:34
From	Victor Lazzarini
Subject	Re: [Cs-dev] remove csoundPreCompile
Attachments	None None
	The order appears correct, but some things will be changed, in particular the ability to compile and load while running, the generation of a fast load representation and similar operations. I would not worry too much about the final look of the API at this stage, but I agree we need to discuss it thoroughly. Victor Lazzarini Michael Gogins <michael.gogins@gmail.com> wrote: I've glanced over the code. Csound has to set its signal handlers, set its environment variables, parse its command line, load modules and plugins, set its callbacks and drivers, set its global variables, reset its heap, parse the orchestra and score into an abstract syntax tree, and compile the abstract syntax tree into a runnable orchestra graph and score, and go into a loop of looking for events and running one kperiod while events are pending, and closing all system resources when no more events are pending. Correct me if that's not the correct order! if it's not the current order, maybe it's a better order. If that's correct, then I think the main API calls and sequence should be csoundCreate -- Creates an instance of Csound and not much else. csoundInitialize -- Does everything up to resetting the heap: takes a message callback for the purpose of diagnostics during initialization, takes no other callbacks or other arguments, has a built-in default message callback (as already exists, prints to stdout). Also exposed: csoundSetSignalHandler, csoundSetXXXCallback, csoundParseArgv, csoundSetEnv, csoundLoadModules, csoundSetGlobal, and I think this would be new, csoundSetArg, also getters for all setters. csoundCompile -- Resets the heap, parses the orc and sco into a tree, compiles the tree into a graph. Also exposed: csoundReset, csoundParseOrc, csoundParseSco, csoundCompileTree csoundPerform -- Loops while events are pending to run one kperiod, calls csoundCleanup when no more events are pending. Also exposed: csoundPerformKsmps to dispatch pending events and runs one kperiod, csoundCleanup to release all system resources. On Mon, Apr 30, 2012 at 8:19 AM, Michael Gogins <michael.gogins@gmail.com> wrote: I can definitely imagine use cases where people would want to change callbacks on a live instance. Debugging, changing audio outputs, etc. Regards, Mike On Mon, Apr 30, 2012 at 6:52 AM, Andres Cabrera <mantaraya36@gmail.com> wrote: I think it should only be for messages, as other callbacks would be less used, and could have their own callback setter. But it makes me think. Would a user want to change any of the callbacks for a csound instance? If it only makes sense to set them once, maybe it would also make sense to have them all as an argument to the csoundCreate function. But in any case, I think the API might look cleaner to most users with my proposal. My only concern is that what I propose is considered bad practice or would be too unusual for most users. Cheers, Andrés On Mon, Apr 30, 2012 at 11:23 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote: > I presume this idea is solely for messages; I guess it does not make sense for other callbacks, or does it? > I am thinking this: > > typedef struct csound_cbs { > ... > } CSOUND_CALLBACKS; > > CSOUND csoundCreate(void userData, CSOUND_CALLBACKS p) > > but that means limiting callback setting to newly created instances. Maybe not a good idea. > > Victor > > On 30 Apr 2012, at 08:43, Andres Cabrera wrote: > >> Hi, >> >> I've been thinking a lot about this lately, and how about setting the >> callback when csound is created? >> >> csound = csoundCreate(0, msg_callback); >> >> I'm thinking about reducing the API, so wherever we can remove a >> function, I think that's a good thing. >> We could also remove the callback setter function (setting the >> callback would only be allowed when creating csound), and if a >> callback is not set, the internal message buffer mechanism is >> activated: >> >> So the functions: >> 1779 void PUBLIC csoundEnableMessageBuffer(CSOUND csound, int toStdOut); >> 1805 void PUBLIC csoundDestroyMessageBuffer(CSOUND csound); >> would go from the public API >> >> and the functions: >> 1784 PUBLIC const char csoundGetFirstMessage(CSOUND csound); >> 1790 int PUBLIC csoundGetFirstMessageAttr(CSOUND csound); >> 1795 void PUBLIC csoundPopFirstMessage(CSOUND csound); >> 1800 int PUBLIC csoundGetMessageCnt(CSOUND csound); >> >> Would only work if no callback has been set. (These four functions >> could even be trimmed and cleaned up to make them more consice). >> >> Thoughts? >> >> Cheers, >> Andrés >> >> >> >> On Fri, Apr 27, 2012 at 4:28 PM, Tito Latini <tito.01beta@gmail.com> wrote: >>> Applied: >>> - removed `csoundPreCompile' >>> - added `csoundSetDefaultMessageCallback' >>> >>> Tested with: >>> >>> static void msg_callback(CSOUND csound, >>> int attr, const char format, va_list args) >>> { >>> (void) csound; >>> printf("===================="); >>> vfprintf(stderr, format, args); >>> } >>> >>> csoundSetDefaultMessageCallback(msg_callback); >>> csound = csoundCreate(0); >>> ... >>> >>> tito >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > Dr Victor Lazzarini > Senior Lecturer > Dept. of Music > NUI Maynooth Ireland > tel.: +353 1 708 3545 > Victor dot Lazzarini AT nuim dot ie > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com