[RTcmix-discuss] auto_load

Fri Sep 30 11:12:48 EDT 2011

At the risk of stepping into a war of philosophy, I think that hiding everything
from the students is a bad idea.  The farther back from an understanding of
what is actually happening they are, the less flexible they are in their creativity.
If they want BOOM, sound, they can play a key on a synth keyboard.  I don't
think RTcmix should strive for black-boxhood.  There are dozens of other software
tools out there for that.

Touched a nerve, there, yah did.

-Doug 

-----Original Message-----
From: Neil Thornock <neilthornock at gmail.com>
To: A discussion list for RTcmix <rtcmix-discuss at music.columbia.edu>
Sent: Fri, Sep 30, 2011 3:38 am
Subject: Re: [RTcmix-discuss] auto_load

Thanks much!

Who knows how useful it might be -- I've been fine without it so far.
But as long as it functions, why not?  I've toyed with the idea of
reducing some of the wordiness of the score.  Like why not have a
default rtsetparams, or a bus_config that somehow automatically
assigns bus numbers, or (in this case) the ability to auto-load
instruments?  It all feels, frankly, a bit dated.  So I could say:

WAVETABLE(0,10,1000,400,0.5)

and BOOM! I've got sound.  I think it would be a gentler introduction
to the program for my students.  I've got a whole list of 'druthers
that I'll probably never really get to.

But still, RTcmix or bust.  Something very satisfying in its graceful
simplicity.

On Fri, Sep 30, 2011 at 7:15 AM, Brad Garton <garton at columbia.edu> wrote:
> Does it also scan the current working directory?  Jes' wonderin'.
> I don't know where it might be useful myself, unless your fingers
> hurt from typing.
> brad
>
> On Sep 29, 2011, at 11:23 PM, Douglas Scott wrote:
>
> OK, so auto_load does work as long as you put it in your .rtcmixrc file.  If
> people are interested in
> this, each profile file (xxxprof.c) for each DSO will need code like I
> showed below.  I know how to
> reduce the warnings (I have already done a bit of work on this) but the
> remaining work is a bit more
> time-consuming.
>
> Oh, and because it scans all the DSOs in the shlib dir, it runs across
> duplicate register attempts
> due to libDMOVE.so and libMMOVE.so registering a lot of the same utility
> functions.
> Where is this feature useful, by the way?
> -Doug
>
> -----Original Message-----
> From: Neil Thornock <neilthornock at gmail.com>
> To: A discussion list for RTcmix <rtcmix-discuss at music.columbia.edu>
> Sent: Thu, Sep 29, 2011 7:09 am
> Subject: Re: [RTcmix-discuss] auto_load
>
> Cool -- thanks for the look.  I wish I had programming chops to hack
> through the code myself... maybe someday...
>
> Neil
>
> On Wed, Sep 28, 2011 at 11:47 PM, Douglas Scott <netdscott at aim.com> wrote:
>> It does appear to produce a lot of complaints from addfunc, still -- I
>> will
>> take a look at what is going on there.
>> -Doug
>>
>>
>>
>> -----Original Message-----
>> From: Douglas Scott <netdscott at aim.com>
>> To: rtcmix-discuss <rtcmix-discuss at music.columbia.edu>
>> Sent: Wed, Sep 28, 2011 6:45 pm
>> Subject: Re: [RTcmix-discuss] auto_load
>>
>> auto_load works -- it's just that nobody has implemented the
>> registerSelf()
>> C function for most of the DSOs.  I did so for MMOVE and MPLACE back when
>> I
>> first wrote the auto load code.  Here is an example from MMOVE:
>> static const char *dsoName = "libMMOVE";
>> // This function is called, if present, by RTcmix at initialization time
>> // when it locates and opens the DSO containing this function.  The call
>> // to registerFunction() takes the string tag for a function that can be
>> // called from a Minc script, and the name of the DSO containing the
>> function.
>> // These should all be the same for any given instrument.
>> //
>> // At the present time, there is no system to handle multiple attempts to
>> // register the same function tag.  Only the first attempt will succeed.
>> //
>> int
>> registerSelf()
>> {
>> registerFunction("MMOVE", dsoName);
>> registerFunction("RVB", dsoName);
>> registerFunction("oldmatrix", dsoName);
>> registerFunction("matrix", dsoName);
>> registerFunction("space", dsoName);
>> registerFunction("mikes", dsoName);
>> registerFunction("mikes_off", dsoName);
>> registerFunction("param", dsoName);
>> registerFunction("cparam", dsoName);
>> registerFunction("path", dsoName);
>> registerFunction("cpath", dsoName);
>>   registerFunction("threshold", dsoName);
>>   registerFunction("set_attenuation_params", dsoName);
>> return 0;
>> }
>>
>> This code sits in the same file as the UG_INTRO calls -- moveprof.c in
>> this
>> case.
>> -Doug
>>
>> -----Original Message-----
>> From: John Gibson <johgibso at indiana.edu>
>> To: A discussion list for RTcmix <rtcmix-discuss at music.columbia.edu>
>> Sent: Tue, Sep 27, 2011 2:53 pm
>> Subject: Re: [RTcmix-discuss] auto_load
>>
>> Doesn't seem to work, though we have some of the infrastructure there.
>>
>> Doug, if you're listening, this is something you worked on. We have the
>> option
>> mechanism and a place in RTcmix.cpp that references Option::autoLoad().
>> The
>> other relevant code is registerDSOs in addcheckfunc.cpp.
>>
>> If this were working, shouldn't this score work?
>>
>> set_option("auto_load = true")
>> rtsetparams(44100, 2)
>> WAVETABLE(0, 10, 4000, 440, .5)
>>
>> No, because auto_load has to be set before the program runs, in the
>> .rtcmixrc
>> file. When you do that and run cmix, you see a lot of error messages from
>> RTcmix::registerFunction, and then it still doesn't work for WAVETABLE.
>>
>> J
>>
>>
>> On Sep 27, 2011, at 3:18 PM, Neil Thornock wrote:
>>
>>> Does auto_load work?  Has it ever?  If so, what am I missing?
>>>
>>> --
>>> Neil Thornock, D.M.
>>> No Stopping, Standing, or Parking:
>>> http://neilthornock.net/mp3s/nostopping.mp3
>>> Assistant Professor of Music
>>> Composition/Theory
>>> Brigham Young University
>>> _______________________________________________
>>> RTcmix-discuss mailing list
>>> RTcmix-discuss at music.columbia.edu
>>> http://music.columbia.edu/mailman/listinfo/rtcmix-discuss
>>
>> _______________________________________________
>> RTcmix-discuss mailing list
>> RTcmix-discuss at music.columbia.edu
>> http://music.columbia.edu/mailman/listinfo/rtcmix-discuss
>>
>> _______________________________________________
>> RTcmix-discuss mailing list
>> RTcmix-discuss at music.columbia.edu
>> http://music.columbia.edu/mailman/listinfo/rtcmix-discuss
>>
>> _______________________________________________
>> RTcmix-discuss mailing list
>> RTcmix-discuss at music.columbia.edu
>> http://music.columbia.edu/mailman/listinfo/rtcmix-discuss
>>
>>
>
>
>
> --
> Neil Thornock, D.M.
> No Stopping, Standing, or Parking:
> http://neilthornock.net/mp3s/nostopping.mp3
> Assistant Professor of Music
> Composition/Theory
> Brigham Young University
> _______________________________________________
> RTcmix-discuss mailing list
> RTcmix-discuss at music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/rtcmix-discuss
>
> _______________________________________________
> RTcmix-discuss mailing list
> RTcmix-discuss at music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/rtcmix-discuss
>
>
> _______________________________________________
> RTcmix-discuss mailing list
> RTcmix-discuss at music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/rtcmix-discuss
>
>

-- 
Neil Thornock, D.M.
No Stopping, Standing, or Parking:
http://neilthornock.net/mp3s/nostopping.mp3
Assistant Professor of Music
Composition/Theory
Brigham Young University
_______________________________________________
RTcmix-discuss mailing list
RTcmix-discuss at music.columbia.edu
http://music.columbia.edu/mailman/listinfo/rtcmix-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/rtcmix-discuss/attachments/20110930/bc18954f/attachment-0001.html>