[RTcmix-discuss] some table documentation questions

Douglas Scott netdscott at netscape.net
Mon Mar 14 12:55:57 EST 2005

johgibso at indiana.edu wrote:

> Brad wrote:
>>While going through the maketable() stuff, I ran into some questions:

>>5.  Suppose I have the following construct:
>>  for (st = 0; st < 10; st = st+1) {
>>      a = maketable("wave", 1000, random(), random(), random())
>>      WAVETABLE(st, 1.5, 10000, ... a)
>>  }
>>I can envision that each instance of WAVETABLE would get a new
>>wave-table-handle via being passed in through the table-handle variable 
>>"a".  I couldn't see in the WAVETABLE code if these tables were ever 
>>delete[]-ed.  Small memory leak of you have an app that produces new 
>>maketables() dynamically (I run looching-like things for hours and hours 
>>here at home.  I'm just that kinda guy).
> Yes, we definitely have memory leak concerns.  But since the app knows how
> long a given table is in use, it could unref it to make it go away *after*
> the instrument is deleted.
PFields are ref'd and unref'd by Instruments, via the PFieldSet class that 
contains them.  When an instrument is destroyed, its PFieldSet unrefs all its 
contained PFields.  When a PField instance's refcount goes to zero and it is 
deleted, it unrefs any PField pointers *it* contains, and so on.  So 
theoretically we know at all times which objects are still being used and which 
are not.  Where does this model break down in the current state of things?

> Should we make this automatic -- e.g., by having instruments ref tables
> and then having them unref them in the destructor?  We'd have to have
> a garbage collector, because the table has to have its refcount bumped
> at construction but before any inst uses it.  So it would take two unrefs,
> one by the inst and one by a garbage collector that runs every now and
> then.
Uuuuughhhhhhhhhh.  You do not want to go there if you care about efficiency. 
Remember Lisp?  [entire program locks up] "garbage collecting......." [program 
runs][program locks up] "garbage collecting......."

> In the interactive score-based case (as opposed to the imbed case), we 
> can't ever delete tables, because they might be used later.
Delete is the wrong word.  These are resources which are reference counted. 
Whoever "uses" them references them.  When each "user" is completely done, it 
unreferences them.

> Doug, what's your position on the whole memory leak issue?  There are 
> many other places in the PField system where this is relevant.
I am very interested in why this does not work the way it is now.  Concern for 
this was built into the model, so I am very motivated to figure out why it is 
> We also have a small leak whenever we create a handle out of a PField
> for passing back to the parser.  Can anything be done about this?
Can you give me a line number?  I will look at this right now.
>>6.  Running maketable("wave", ... ) without the "interp" being explicitly 
>>listed sounds uninterped to me, but I think I may be imagining things.  
>>The code *looks* like the interp is being done.  Weird.
> Well, this is a confusing situation.  The reason this is happening is
> that WAVETABLE gets the raw table and feeds that to Ooscili, which 
> does linear interpolation no matter what.  The "interp" options for
> tables are relevant for any parameter that enters an instrument via
> the update() call.  So try a very small table controlling amplitude,
> say with a random table, and you should be able to hear the difference.
> But I agree that it's misleading, because you would expect the interp to
> table arg to affect the treatment of the wavetable.  Actually, this is
> true any time an inst grabs a table from the system, as in a grain envelope.
> It then takes charge of interpolation, since the values are not accessed
> via the PField object.

And this is the rat hole you have dropped down by doing direct access of tables 
rather than accessing them via their API.

> It's possible that we could have some mechanism whereby an instrument
> could find out how the table is meant to be interpreted, but this would
> go against the grain of Doug's scheme, whereby the client of the PField
> can't know whether the table is being interpolated (because this is done
> via a static method that's selected at table construction).
This would be the worm hole at the bottom of the rat hole, and it never ends, 
trust me.

Please, please -- rather than thinking of the hack that would get specific 
instance X to do what you want, can we come up with a description of the general 
problem we are facing with regard to "any time an inst grabs a table from the 
system" (quoted from above)?


More information about the RTcmix-discuss mailing list