<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for 74Objects</title>
	<atom:link href="http://blog.74objects.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.74objects.com</link>
	<description>design, music, interaction, art, machines, and code</description>
	<lastBuildDate>Mon, 25 Jan 2010 20:34:17 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Peacock&#8217;s Interface Design by Timothy Place</title>
		<link>http://blog.74objects.com/2009/03/29/peacocks-interface-design/#comment-67</link>
		<dc:creator>Timothy Place</dc:creator>
		<pubDate>Mon, 25 Jan 2010 20:34:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=12#comment-67</guid>
		<description>Another graphical data-flow app is demoed in a video @ http://www.refractivesoftware.com/videos.html .  This app runs on a local machine using the GPU for rendering rather running in the web-browser.</description>
		<content:encoded><![CDATA[<p>Another graphical data-flow app is demoed in a video @ <a href="http://www.refractivesoftware.com/videos.html" rel="nofollow">http://www.refractivesoftware.com/videos.html</a> .  This app runs on a local machine using the GPU for rendering rather running in the web-browser.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Less is Less by Timothy Place</title>
		<link>http://blog.74objects.com/2009/11/15/less-is-less/#comment-65</link>
		<dc:creator>Timothy Place</dc:creator>
		<pubDate>Mon, 21 Dec 2009 14:49:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=333#comment-65</guid>
		<description>One more less-is-less example that I think is a poignant &#039;tape&#039; piece by Brian Belet called “Name Droppings”.  The piece is a critique of the vita/resume/bio process.  

So often these pages or paragraphs are all so much filler and fluff to mask who we really are and what we&#039;ve really (not) done!</description>
		<content:encoded><![CDATA[<p>One more less-is-less example that I think is a poignant &#8216;tape&#8217; piece by Brian Belet called “Name Droppings”.  The piece is a critique of the vita/resume/bio process.  </p>
<p>So often these pages or paragraphs are all so much filler and fluff to mask who we really are and what we&#8217;ve really (not) done!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Less is Less by Timothy Place</title>
		<link>http://blog.74objects.com/2009/11/15/less-is-less/#comment-48</link>
		<dc:creator>Timothy Place</dc:creator>
		<pubDate>Tue, 17 Nov 2009 12:19:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=333#comment-48</guid>
		<description>I agree!</description>
		<content:encoded><![CDATA[<p>I agree!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Less is Less by Jean-François Charles</title>
		<link>http://blog.74objects.com/2009/11/15/less-is-less/#comment-47</link>
		<dc:creator>Jean-François Charles</dc:creator>
		<pubDate>Mon, 16 Nov 2009 16:23:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=333#comment-47</guid>
		<description>Hi Tim, thanks for this post. I like that you use the term &quot;expressive&quot;. Sometimes, live electronics performers manage to be quite expressive and to &quot;hide&quot; some of their set-up (at least the audience does not focus on the &quot;electronics&quot;): electric guitar players (in many different contexts) are good at both.</description>
		<content:encoded><![CDATA[<p>Hi Tim, thanks for this post. I like that you use the term &#8220;expressive&#8221;. Sometimes, live electronics performers manage to be quite expressive and to &#8220;hide&#8221; some of their set-up (at least the audience does not focus on the &#8220;electronics&#8221;): electric guitar players (in many different contexts) are good at both.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Custom Data-Types in Max Part 3: Binding to Symbols by Leigh Hunt</title>
		<link>http://blog.74objects.com/2009/04/07/custom-data-types-3/#comment-46</link>
		<dc:creator>Leigh Hunt</dc:creator>
		<pubDate>Sat, 14 Nov 2009 05:37:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=122#comment-46</guid>
		<description>Hi Timothy,
Quick update, for the sake of other people looking over these pages, silly me was storing a pointer to the object&#039;s box, rather than a pointer to the object... not surprising that I couldn&#039;t get my attribute from the looked-up pointer.
Everything works great now. Thanks again
Leigh</description>
		<content:encoded><![CDATA[<p>Hi Timothy,<br />
Quick update, for the sake of other people looking over these pages, silly me was storing a pointer to the object&#8217;s box, rather than a pointer to the object&#8230; not surprising that I couldn&#8217;t get my attribute from the looked-up pointer.<br />
Everything works great now. Thanks again<br />
Leigh</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Custom Data-Types in Max Part 3: Binding to Symbols by Leigh Hunt</title>
		<link>http://blog.74objects.com/2009/04/07/custom-data-types-3/#comment-44</link>
		<dc:creator>Leigh Hunt</dc:creator>
		<pubDate>Tue, 20 Oct 2009 13:41:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=122#comment-44</guid>
		<description>Hi again Timothy,
Regrettably not 100% clear.... ho hum on me!...

Am I storing correctly the object pointer here?....
note - tempbuf is a char array made from obj name/patcher name.
eg ::trk1::auxvol[1]

&lt;pre&gt;
t_object *b;
b = (t_object *)gensym(&quot;#B&quot;)-&gt;s_thing; 
t_hashtab *tab;
tab = (t_hashtab*)gensym(&quot;leighsobjecttable&quot;)-&gt;s_thing;
hashtab_store(tab, gensym(tempbuf), (t_object *)b);
&lt;/pre&gt;

Or is it my lookup that is incorrect?.....

&lt;pre&gt;
t_object  *t;
t_hashtab *tab;
long n; 
t_symbol *test; (is passed name of key - rg ::trk1::auxvol[1])
tab = (t_hashtab*)gensym(&quot;leighsobjecttable&quot;)-&gt;s_thing;	
hashtab_lookup(tab, test, &amp;t);								
n = object_attr_getlong(t, gensym(&quot;param_value&quot;));
&lt;/pre&gt;

I receive no error message, nor the long value I am trying to retrieve unfortunately. I have simply replaced a symbol-&gt;s-thing object pointer system with these hashtable parts, so I discount any other possible sources of the problem, eg incorrectly formatted char arrays/symbols.

When I print out a list of keys from my hashtable object it shows them all as being there, so I&#039;m sure I&#039;m missing something again, either in the storage or the lookup of the object pointer.
Many thanks should you get a moment to browse over this.

Cheers,
Leigh</description>
		<content:encoded><![CDATA[<p>Hi again Timothy,<br />
Regrettably not 100% clear&#8230;. ho hum on me!&#8230;</p>
<p>Am I storing correctly the object pointer here?&#8230;.<br />
note &#8211; tempbuf is a char array made from obj name/patcher name.<br />
eg ::trk1::auxvol[1]</p>
<pre>
t_object *b;
b = (t_object *)gensym("#B")-&gt;s_thing;
t_hashtab *tab;
tab = (t_hashtab*)gensym("leighsobjecttable")-&gt;s_thing;
hashtab_store(tab, gensym(tempbuf), (t_object *)b);
</pre>
<p>Or is it my lookup that is incorrect?&#8230;..</p>
<pre>
t_object  *t;
t_hashtab *tab;
long n;
t_symbol *test; (is passed name of key - rg ::trk1::auxvol[1])
tab = (t_hashtab*)gensym("leighsobjecttable")-&gt;s_thing;
hashtab_lookup(tab, test, &amp;t);
n = object_attr_getlong(t, gensym("param_value"));
</pre>
<p>I receive no error message, nor the long value I am trying to retrieve unfortunately. I have simply replaced a symbol-&gt;s-thing object pointer system with these hashtable parts, so I discount any other possible sources of the problem, eg incorrectly formatted char arrays/symbols.</p>
<p>When I print out a list of keys from my hashtable object it shows them all as being there, so I&#8217;m sure I&#8217;m missing something again, either in the storage or the lookup of the object pointer.<br />
Many thanks should you get a moment to browse over this.</p>
<p>Cheers,<br />
Leigh</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Custom Data-Types in Max Part 3: Binding to Symbols by Leigh Hunt</title>
		<link>http://blog.74objects.com/2009/04/07/custom-data-types-3/#comment-43</link>
		<dc:creator>Leigh Hunt</dc:creator>
		<pubDate>Mon, 19 Oct 2009 15:10:26 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=122#comment-43</guid>
		<description>Hi !
&#039; s-&gt;s_thing = (t_object*)h; &#039;  - I hadn&#039;t come across this method of binding, or at least not knowingly!
Thanks muchly !</description>
		<content:encoded><![CDATA[<p>Hi !<br />
&#8216; s-&gt;s_thing = (t_object*)h; &#8216;  &#8211; I hadn&#8217;t come across this method of binding, or at least not knowingly!<br />
Thanks muchly !</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Custom Data-Types in Max Part 3: Binding to Symbols by Timothy Place</title>
		<link>http://blog.74objects.com/2009/04/07/custom-data-types-3/#comment-42</link>
		<dc:creator>Timothy Place</dc:creator>
		<pubDate>Mon, 19 Oct 2009 15:03:34 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=122#comment-42</guid>
		<description>A hashtab is a real Max object, meaning that the first member of it&#039;s struct is a t_object.  So you should be able to safely cast your hashtab pointer to to the s_thing.

&lt;pre&gt;
t_hashtab* h = hashtab_new(2027); // prime numbers work well for size
t_symbol* s = gensym(&quot;foo&quot;);

s-&gt;s_thing = (t_object*)h;
&lt;/pre&gt;

Of course, blindly assigning to the s_thing as I did here is not safe as detailed in the article above.

Cheers!</description>
		<content:encoded><![CDATA[<p>A hashtab is a real Max object, meaning that the first member of it&#8217;s struct is a t_object.  So you should be able to safely cast your hashtab pointer to to the s_thing.</p>
<pre>
t_hashtab* h = hashtab_new(2027); // prime numbers work well for size
t_symbol* s = gensym("foo");

s-&gt;s_thing = (t_object*)h;
</pre>
<p>Of course, blindly assigning to the s_thing as I did here is not safe as detailed in the article above.</p>
<p>Cheers!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Custom Data-Types in Max Part 3: Binding to Symbols by Leigh Hunt</title>
		<link>http://blog.74objects.com/2009/04/07/custom-data-types-3/#comment-41</link>
		<dc:creator>Leigh Hunt</dc:creator>
		<pubDate>Mon, 19 Oct 2009 14:38:26 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=122#comment-41</guid>
		<description>Hi Timothy,
Thanks for your prompt reply. 
Your suggestion makes perfect sense to me. I&#039;d never looked at hashtabs.

I can see how to create an external that contains a hashtab (which I would place one instance of in my main patcher), 
I&#039;m a little perplexed as to how to bind the hashtab to a symbol, at least the syntax for doing such a thing. In xcode I tried binding to both the symbol and the s_thing field of a symbol but I get an &#039;incompatible pointer type&#039; error. I guess I am overlooking something.

&#039; I’m not really sure what you are doing &#039; - It&#039;s rather complicated to explain, but it is a system for interacting with the Mackie series of control surfaces MCU/XT/C4. I intend to start documenting online soon. I&#039;ll post you a link when this happens if you like. 
Currently the development has is tailored to my setup, but once I am done I intend to make a more open version so people can easily incorporate the system into their existing setup, freebie externals of course!

Thanks again for your time, it&#039;s much appreciated. If you are ever in Europe in need of a live sound engineer, then maybe I can repay you for your troubles! 
Kind regards,
Leigh</description>
		<content:encoded><![CDATA[<p>Hi Timothy,<br />
Thanks for your prompt reply.<br />
Your suggestion makes perfect sense to me. I&#8217;d never looked at hashtabs.</p>
<p>I can see how to create an external that contains a hashtab (which I would place one instance of in my main patcher),<br />
I&#8217;m a little perplexed as to how to bind the hashtab to a symbol, at least the syntax for doing such a thing. In xcode I tried binding to both the symbol and the s_thing field of a symbol but I get an &#8216;incompatible pointer type&#8217; error. I guess I am overlooking something.</p>
<p>&#8216; I’m not really sure what you are doing &#8216; &#8211; It&#8217;s rather complicated to explain, but it is a system for interacting with the Mackie series of control surfaces MCU/XT/C4. I intend to start documenting online soon. I&#8217;ll post you a link when this happens if you like.<br />
Currently the development has is tailored to my setup, but once I am done I intend to make a more open version so people can easily incorporate the system into their existing setup, freebie externals of course!</p>
<p>Thanks again for your time, it&#8217;s much appreciated. If you are ever in Europe in need of a live sound engineer, then maybe I can repay you for your troubles!<br />
Kind regards,<br />
Leigh</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Custom Data-Types in Max Part 3: Binding to Symbols by Timothy Place</title>
		<link>http://blog.74objects.com/2009/04/07/custom-data-types-3/#comment-40</link>
		<dc:creator>Timothy Place</dc:creator>
		<pubDate>Sun, 18 Oct 2009 16:07:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.74objects.com/?p=122#comment-40</guid>
		<description>Thanks for comments!

Max&#039;s symbol table is a hash table (http://en.wikipedia.org/wiki/Hash_table) with a reasonably large number of buckets.  It is good to be cautious about bloating the symbol table though, because it affects the performance the entire application.  So, 1000 symbols should not degrade Max&#039;s performance too much.  I would get start getting nervous if you were talking about 10000+ symbols.

Should you worry about other Max objects stepping on your pointers stored in a t_symbol::s_thing?  Yes.  Ideally all Max objects should be good citizens and not overwrite an s_thing if it has a value already.  In reality, this is not enforced in the Max API.  For example, can you count on all other third parties being careful about this when they might not have read about how to work with the s_thing?

I&#039;m not really sure what you are doing, but there is another approach you might consider.  Instead of binding an individual pointer to an individual s_thing, you could create a t_hashtab, and then bind that to one special symbol that is unlikely to be used, such as
&lt;pre&gt;
 gensym(&quot;__++mySpecialSymbol##$$??&quot;).  
&lt;/pre&gt;

Then store your pointers in this hashtab, with a the symbols are the keys.  When any of your objects needs to get a pointer, it gets the hashtab pointer from your special symbol, and then gets the pointer by looking it up in that hashtab.  This way you have symbols associated with pointers, you can access them from anywhere, and they are scoped to your situation so that you don&#039;t conflict with the global environment.

Hope this helps!</description>
		<content:encoded><![CDATA[<p>Thanks for comments!</p>
<p>Max&#8217;s symbol table is a hash table (<a href="http://en.wikipedia.org/wiki/Hash_table" rel="nofollow">http://en.wikipedia.org/wiki/Hash_table</a>) with a reasonably large number of buckets.  It is good to be cautious about bloating the symbol table though, because it affects the performance the entire application.  So, 1000 symbols should not degrade Max&#8217;s performance too much.  I would get start getting nervous if you were talking about 10000+ symbols.</p>
<p>Should you worry about other Max objects stepping on your pointers stored in a t_symbol::s_thing?  Yes.  Ideally all Max objects should be good citizens and not overwrite an s_thing if it has a value already.  In reality, this is not enforced in the Max API.  For example, can you count on all other third parties being careful about this when they might not have read about how to work with the s_thing?</p>
<p>I&#8217;m not really sure what you are doing, but there is another approach you might consider.  Instead of binding an individual pointer to an individual s_thing, you could create a t_hashtab, and then bind that to one special symbol that is unlikely to be used, such as</p>
<pre>
 gensym("__++mySpecialSymbol##$$??").
</pre>
<p>Then store your pointers in this hashtab, with a the symbols are the keys.  When any of your objects needs to get a pointer, it gets the hashtab pointer from your special symbol, and then gets the pointer by looking it up in that hashtab.  This way you have symbols associated with pointers, you can access them from anywhere, and they are scoped to your situation so that you don&#8217;t conflict with the global environment.</p>
<p>Hope this helps!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
