On Sep 8, 2011, at 12:59 PM, Hans-Christoph Steiner wrote: > > On Sep 7, 2011, at 5:46 PM, Jonathan Wilkes wrote: > > > ----- Original Message ----- > > > > > From: Hans-Christoph Steiner <[email protected]> > > > To: Jonathan Wilkes <[email protected]> > > > Cc: fbar <[email protected]>; "[email protected]" <[email protected]> > > > Sent: Tuesday, September 6, 2011 4:04 PM > > > Subject: Re: [PD] (breaking symbols) was Re: find a list of > > > numbers in a text file > > > > > > > > > On Sep 6, 2011, at 12:30 PM, Jonathan Wilkes wrote: > > > > > > > ----- Original Message ----- > > > > > > > > > From: fbar <[email protected]> > > > > > To: "[email protected]" <[email protected]> > > > > > Cc: > > > > > Sent: Tuesday, September 6, 2011 3:53 AM > > > > > Subject: Re: [PD] (breaking symbols) was Re: find a list of > > > > > numbers in > > > a text file > > > > > > > > > > On Tue, Sep 06, 2011 at 09:44:33AM +0200, Frank Barknecht > > > > > wrote: > > > > > > I'm not sure what "appears in the patch" should mean. > > > It > > > > > definitly means > > > > > > that numercial-symbol selectors don't get shown and cannot > > > > > > be > > > written > > > > > > into a patch, so you cannot use them in the editor where > > > "real" > > > > > > selectors should be written, like in [route]. > > > > > > > > > > Forgot to add: Of course it is possible and legal to "use" > > > numerical > > > > > or > > > > > non-printable symbols as selectors, but they have to be > > > > > constructed > > > > > dynamically and cannot be typed, in accordance with the > > > > > restrictions > > > > > mentioned in the manual. Instead something like this can be > > > > > used: > > > > > > > > > > [makefilename %d] > > > > > | > > > > > | [makefilename %d] > > > > > | | > > > > > [select symbol-dummy] > > > > > > > > > > I used [makefilename %d] a lot in the rj library's > > > > > [m_chorddict] > > > > > dictionary for chords, where some chord names are proper > > > > > symbols, like > > > > > "m7", while others are floats like 7. The float-names get > > > converted to > > > > > symbols internally to look up chord notes in a data structure > > > > > array > > > > > keyed by symbols only (using [m_symbolarray]). > > > > > > > > At what point are you using numerical-symbol selectors? > > > > Everything > > > you've > > > > described has the selector 'symbol'. > > > > > > > > If you mean you let the user send symbols or floats as the key > > > > and convert > > > > internally, that's _exactly_ what I'm proposing. > > > > > > I guess I'm not clear on your proposal. Is it that a "symbol" > > > selector automatically converts things to a symbol? That makes a > > > lot of sense, > > > and would help with other issues. Then you could also make > > > symbols with spaces, > > > like: > > > > > > [symbol 43( > > > [symbol /home/hans/My Documents( > > > > Well, that's something I've wanted for a long time. But what I am > > proposing has to do with > > selectors, not symbol messages. > > > > Problem: convert from symbol-atom to float-atom > > Proposal: if a selector happens to be in a form that can be > > interpreted by the > > naked eye as a valid Pd float, and the object receiving the message > > has a float method > > (and no anything method), then send a float to the object. > > > > [r infinite-expressivity] > > | > > [1( <- float > > | > > [makefilename %d] <-- converted to symbol message (and the message > > arg is convert to a symbol-atom) > > | > > [list trim] <-- now we have a message with the selector 1 and no > > arguments > > | > > [route float] <-- seriously, it's a symbol-atom, not a float > > | > > ------------+ > > | > > [float] <-- my proposal: give [float] a float-atom instead of a > > symbol-atom in this case > > | > > [route float] > > | > > [set $1, bang( > > | > > [s infinite-expressivity] > > > > But if there were a really nice quoting mechanism, that would > > probably be much clearer. > > Yes, I agree that [float] and [symbol] should also do conversions. A > good example would be Python's str() and float(). > > > > > etc. > > > > > > A quoting mechanism would also help. We could probably get away > > > with only > > > \. For example, \ for spaces, like: > > > > > > [symbol /home/hans/My\ Documents( > > > [symbol I\ like\ lots\ of\ \ \ \ \ spaces( > > > [symbol commas\,\ in\ symbols( > > > [symbol semi-colon\;\ in\ symbols( > > > > That looks really ugly to me. What's wrong with "quotes"? > > The nice part would be that it would only add one special character, > \, which is currently not allowed anyway. Adding "" or '' or `` > quotes means some kind of backwards incompatibility, since '"` are > currently all valid characters to have in a symbol. Another easy > option would be to use > > I think this would be made much easier if the symbol selector forced > the message to be a symbol, then you could do: > > [symbol /home/hans/My Documents( > [symbol I like lots of\ \ \ \ \ spaces( > [symbol commas\, in symbols( > [symbol semi-colon\; in symbols( > [symbol \43( > [symbol \-21343( > [symbol \-0.2e59( > > Then you'd only need the \ when its in other places, like: > > [route \43] > > > > And last but least, and its already in there: > > > > > > [symbol \43( > > > [symbol \-21343( > > > [symbol \-0.2e59( > > > > > > Anything that just \ couldn't cover? > > > > [openpanel] <- outputs /home/hans/My documents > > | > > [set symbol $1( > > | > > [ ( <-- What's printed here? ...My documents or ...My\ documents? > > > Depends on what the symbol selector does. If the symbol selector > forces the rest of the message to be a symbol, then there wouldn't > need to be any backslashes there. But it would probably be a good > idea to have them there anyway. >
Here's an example of this idea applied to the [symbol] and [float] boxes. https://github.com/pd-projects/newtype Also, I attached a Linux 32-bit version and a Mac OS X universal. .hc ---------------------------------------------------------------------------- News is what people want to keep hidden and everything else is publicity. - Bill Moyers
newtype.tar.bz2
Description: application/bzip-compressed-tar
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
