<br><br><div><span class="gmail_quote">On 19/11/2007, <b class="gmail_sendername">Ge Wang</b> <<a href="mailto:ge@ccrma.stanford.edu">ge@ccrma.stanford.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi!</blockquote><div><br>Hi Ge!<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is bug, where the internal ID is uninitialized for user instantiated
<br>Shred instances. This has been fixed in CVS (unsporked shreds id default<br>to 0).</blockquote><div><br>Very good! I now see why normal shreds don't start counting at 0 like everything else, good solution.<br><br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> However, it brings up the bigger question of what this user<br>created Shred might be used for, since currently, there is no facility to
<br>spork from these Shred objects (at the moment, Shred instances are<br>internally created and can be accessed afterwards). For now, perhaps it<br>makes sense to disable Shred instantiation from code? Thoughts?</blockquote>
<div><br>Yes, I admit I have no real use for them right now but if<br><br>spork ~ my_function() @=> Shred foo;<br><br>is useful (and I think it is, giving shreds names might lead to more readable code if we are dealing with a situation where we need to remove shreds from the VM) then I'd say creating a array of empty Shred objects would be useful too. We could assign shreds to them as they get sporked and deal with larger numbers of shreds with less efford. I could imagine this getting useful if we have shreds that represent something like synth voices, we know how many the CPU can take and we want some sort of voice management or something. How useful this is depends more or less on the member functions the Shred object has. .exit() and .id() were easy to assume but are there more? The documentation is rather vague about that class, aside from noting it exists.
<br><br>class Super_shred extends Shred { //blahblah}<br><br>....on the other hand gives us a object that can't be used for anything right now so I would be fine with disabling that until somebody has a good idea on how to use a thing like that.
<br> </div><br>Not the most fruitful of experiments, this, so far, but I do quite like the idea of making the variables that the function had accessible as members of the object that it becomes once sporked. How hard would that be to implement? It's not worth a lot of work as we can get equivalent functionality by using a class and sporking from there but as a concept it makes sense to me, particularly with regard to inter-shred communication at low syntax-overhead. I'd say that's a topic that does deserve our attention in the coming time but perhaps there are better ideas.
<br><br><br>Also, that whole "scope" thing to the --shell, is that a plan that has since been discarded and and should I stop lusting after it? That sort of functionality is the one thing I envy our friends in the SuperCollider world over. I've been talking about that rather a lot and if there was some sort of outline like say "we won't do it for now" or -say- "after garbage collection" I could relax about it on the list/ WiKi, I'm sure people are quite bored with me going "I want that, preferably graphically in the Mini" all the time by now :¬).
<br><br><br>Thanks for your help, hope you are well,<br>Kas.<br></div>