@ddw_music Hello again! Thanks for linking me to your other reply. I tried patching up the code as described, but I'm not getting any output to the list. Can you tell me more about which ASCII codes are worth trying in the Select object? I see on the ASCII table that they correspond to Line Feed and Carriage Return, but I don't think I understand enough about how ASCII works to know which others are worth trying.

Here's a screenshot of the code, in case there is something else I missed -

Thanks again for your help!

It depends on how the Python script is written, but often [comport] gets ASCII codes for a string representation of the values, not a linear mapping of the values themselves.

I think that's the case here because: 1/ a "CR-LF" pair (carriage return - line feed) uses ASCII codes 13 and 10, where 10 conspicuously matches the lower bound you observed, and 2/ decimal digits are ASCII codes 48 to 57, which is kind of close to 60.

I think there are other threads on this forum showing how to reassemble the comport bytes into strings and convert them into real numbers. ... such as: https://forum.pdpatchrepo.info/topic/15143/help-parsing-continuous-serial-float-stream-from-arduino-into-pure-data/2 -- note that the cables coming out of [t b b] crisscross going into the [list store] (output first, then reset).

hjh

Is Perfection Important?
Exploring the Sound through the Fibonacci Sequence

Application deadline: Nov. 18, 2023, 12am
Submission Email: lyd15150099208@gmail.com
Website:https://www.yadong.uk/process-2-1/event-one-jn7aa

Music and Data Convergence: A Call for Creators

The intersection of music and data offers a realm of boundless possibilities. Both fields rely on precise symbols to convey information, creating a parallel between musical notes and data records. Just as performers and listeners immerse themselves in the musical experience, data enthusiasts observe and record the ever-evolving world of information. In this context, stages and instruments become the equivalent of facts and observations, bridging the gap between music and data.

While music and data aren't identical systems, music can be seen as a unique way to represent data. It's not just about recording and playing notes; it's about reimagining music from a data perspective. Our goal is to unlock infinite possibilities, sparking creativity at the intersection of data and music.

Open Call: Crafting Perfection with the Fibonacci Sequence

The Fibonacci sequence, a mesmerizing pattern found in nature and the arts, offers an exciting creative opportunity. Starting with 0 and 1, each number in the sequence is the sum of the two preceding numbers (1+1=2, 1+2=3, 2+3=5, and so on). This sequence often leads to the golden ratio (approximately 1.618), a cornerstone in creating aesthetically pleasing designs in art and architecture.

I invite artists, musicians, and visionaries of all levels to explore the potential of this sequence in crafting perfect sound art. Use the data series that represents perfection to create works of sonic wonder.

If this piques your interest, please share your artwork or ideas with us via email. We'd love to hear about your creative process and vision.

Selected works have the chance to be featured in our upcoming online exhibition.

Join us in the exploration of data and sound, as we redefine the boundaries of creativity at the nexus of music and information.

@jameslo said:

I'd still like to know if spaces are legal and possible with [oscformat] though.

I'm a bit surprised to see this, but in fact, according to the OSC spec 1.0, spaces are not allowed in OSC command paths.

https://ccrma.stanford.edu/groups/osc/spec-1_0.html#osc-address-spaces-and-osc-addresses

Each OSC Method and each OSC Container other than the root of the tree has a symbolic name, an ASCII string consiting of printable characters other than the following:

-character-	-name-	-ASCII code (decimal)-
’ ’	space	32
#	number sign	35
*	asterisk	42
,	comma	44
/	forward slash	47
?	question mark	63
[	open bracket	91
]	close bracket	93
{	open curly brace	123
}	close curly brace	125

So Pd has no obligation to support spaces here.

I suppose it depends on the software's OSC handler. SuperCollider doesn't complain (contrary to the OSC spec):

n = NetAddr.localAddr;  // send to myself

o = OSCFunc({ |msg|
    msg.postln;
    o.free;
}, '/test space');

n.sendMsg('/test space', 1);

prints: [ /test space, 1 ]

I did some other tests:

• "symbol patch 1" --> [list fromsymbol]: escape char 92 is not in the ASCII list.
• list "112 97 116 99 104 32 49" --> [list tosymbol]: resulting symbol prints with a backslash. I don't know if the backslash is stored internally, or if it's inserted only for the printed output. A quick look at the source code in x_list.c suggests that the backslash is not stored internally.
• list "112 97 116 99 104 32 49" --> [list tosymbol] --> [list prepend set] --> [list trim] --> [oscformat]: The printed bytes from oscformat do include char 92. But I couldn't see in the source code where the space is being escaped. (This long way around to build the "set" message is to be certain that there's no backslash in my input -- the backslash must be generated internally somewhere..)

So [oscformat] seems to be where the problem is happening -- but the OSC spec makes no promises that spaces will work, so there wouldn't be any justification to log a bug.

hjh

@KMETE

OK, here are a couple of test patches. Be sure to save them in the same directory with the audio files (to test relative-path file access).

The first one checks the basic behavior of soundfiler. If neither of these tests is OK, then nothing is going to work.

I'm suggesting this test because -- in your original patch, you're using soundfiler with a relative path "G2001.wav" and this is OK. Using [stereofile], you've tried a full path "/Users/...../G1001.wav" and this was not OK. (Also known is that both relative and full paths are fine on my machine.)

Experimentally, that's two variables: soundfiler vs stereofile, and relative vs full path. So it's impossible to say which one of those causes the problem, with the available information. To figure that out, we have to test basic soundfiler usage with both types of path.

test-1-2.pd

Check the Pd console window for "no such file or directory" errors, and copy/paste those errors into your message.

One possible issue here is non-ASCII (non-English) characters. The relative path "G1001.wav" consists entirely of ASCII characters, but based on your first screenshot, I might guess that part of your full path could include characters outside of the 0-127 ASCII code points. I've seen Pd choke on this before. I thought this was fixed in recent versions, but maybe there are still issues in Mac?

Second file tests relative vs full paths with stereofile.

test-3-4.pd

Last -- I added a [print] object into one of the abstractions to verify the "read" message (locally, you don't have this): "read -resize -skip 0 test-audio.wav test3_LEFT test3_RIGHT" -- it's fine.

Last last -- are you using [dac~ 1 2] or something else? The ezoutput~ in my demo patch routes to 1 and 2. If you are using different dac~ channels, this could be another reason why you're hearing left only. (I assumed that you know your studio's channel layout and that you would substitute an appropriate output object.)

hjh

@Johnny-Mauser Yes, I thought so at first.
But it returns the ASCII decimal values for example of the characters D and E separately...... list D E
What is needed is the decimal value of the 8-byte HEX DE.
There is no decimal ascii value for a character DE as the character does not exist.

It would be possible using [list fromsymbol] and some maths but it is complicated because when the list is split using [list split 1] the second outlet continues to output the remembered 2nd value (E) when there is no new value....... i.e. for decimal 0 to 15 (HEX 00 to 0F).
David.

@Tombot7 It is sending the decimal value of ASCII characters....... not floats.
ASCII 13 is "carriage return" and ASCII 10 is "line feed".
They are reserved characters (all decimal values 0-31) are functions and do not print).
13 and 10 are nearly the same thing but not exactly...... "line feed" does not return the cursor to the start of the new line.
Anyway, I am surprised at the translation as I would expect the same UNIX behaviour on a Mac and an RPI. I have no idea why the RPI would change the value.
Of course you receive the decimal values as integers and can use them as such in Pd.
David.

@Coalman Maybe define the send as ascii or convert to a string of the decimal values of the ascii characters in python before sending? ......... https://www.codegrepper.com/code-examples/python/ascii+to+decimal+python
[list tosymbol] will convert the decimal back to characters in Pd........ and it might then be easier to diagnose any problems.

Also there is a dedicated binary in your Pd distribution called pdsend (it is in the bin folder along with the Pd binary). It can be called in Python (probably needs to be copied to a folder where Python will find it).
Then use [netreceive] in Pd to receive what is sent through pdsend.
There is a code snippet here........ https://guitarextended.wordpress.com/2012/11/03/make-python-and-pure-data-communicate-on-the-raspberry-pi/ ...... unfortunately a screenshot so it will need to be typed out again.

BUT the comma in the message "IU.SFJD.00.BHZ | 2021-08-19T12:45:49.019538Z - 2021-08-19T12:46:05.269538Z | 20.0 Hz, 326 samples" will split the message when it arrives in Pd.
AND more importantly.... I am pretty sure that a pipe "|" in Python passes information (before the pipe) to an operator (after the pipe) and that could be why the message fails....... trying to pass "IU.SFJD.00.BHZ" to a non-existent operator "2021-08-19T12"
David.

I have never made "Art" to make money. ...Really, only to keep sane.

And because...largely, I operate on the belief...feeling...that someone may benefit (esp. those feeling lo/blue/etc.) from my work.

So...if ads do come up on my videos...blame Google. For I am not the one to apologize for them.

I am sorry, however, that our civilizations has not yet(!) evolved past the point where such resources are "free".

I do hope you can look past any ads, etc., that may come up and successfully dissociate from the ideas they would like to proliferate:

that my work is intended to make money;
that All art is intended to make money;
that one can not make Art without wanting to make money.

Peace through (information ) Sharing.
Love through giving.

Happy PD-ing.

May your work flow freely and easily through you today and All days.

-s

p.s. as I said once...a long time ago..."Give it ALL a way to go free".
p.p.s. the videos here are via "Unlisted" videos. So if you do happen share them, I ask that you include the above. Thank you.

If you're measuring search, last I looked it's just a simple linear search with [text] classes.

The point is that Pd doesn't have a properly optimized associative table implementation in vanilla.

Well, it does-- it is the global symbol table which t_symbol hooks into.

There are all these leaky parts between the language and the implementation-- I think it's what you are noticing when a solution gets produced from "on high." The user either has pentested potential workarounds enough to know which constructions are likely to be performant, or they've looked under the hood to see how things are implemented.

For example, when I said this in the other thread:

At least when I look at OP's problem, I see global receiver names followed by messages.

It's because I know that the global receiver names are a) created using a simple, effective hashing algo, and their associations are already cached by the time a symbol becomes part of a message. So the cost of forwarding a message to a receiver is just the cost of message evaluation plus the cost of invoking the relevant receiver's function in pd_typedmess. Since the user obviously knows how many arguments each receiver expects, they can skip iterating over the args in order to forward the next message. No lookups or data copying is needed.

TL;DR I would love to see more robust and well-performing data structures in Pd.

Yeah, I'd be curious to know after jumping into Pd if you have any opinions on what they could look like or at what level they could be implemented. IMO a decent associative array implementation ought to fill most niches. The demo solution I wrote that @jona found could be expanded to make things more expressive. (It just reimplements Pd's t_symbol hashing algo in a subpatch.) But of course it would be limited to that particular class/object-- you couldn't use it to pass around an associative array. (I guess gpointers could be used to do this, but that's not a great UX IMO.)

It's also possible to add something at the level of a native data type, at the cost of all the thinking about new syntax and compatibility that requires.

Edit: my letter b above got converted to a sunglasses-smily emoji. I like it.