i'm having similar problems when trying to use firmata with a teensy 3.2 on windows with PD vanilla. The teensy works fine when using the firmata-test.exe or windows remote arduino experience app. But using pduino PD i can't connect to the teensy and sometimes PD crashes.

Note i had to edit the boards.h file in the Arduino firmata library to get firmata to compile for teensy 3.2

@lgarcial I have never seen [dumpOSC] complain about the message address before.
And the float number arriving is not formatted as a float or a symbol.
So the incoming message from Grasshopper 3D is not in the correct OSC format.
It looks as though the header and the float have been formatted as a string.

Would you please close your patch and make a new one containing the object [netreceive 6000 1] connected to a [print] and then post an example of the messages printed to the terminal when Grasshopper 3D is sending OSC.....

You might also be lucky if you try using [netreceive -u -b] and [oscparse] ...... (both in later versions of Pd Vanilla though)..... but I doubt it......
David.

@romulovieira-me It should be very simple using MrPeach.

If you are using Pd-extended you need [import mrpeach]
For Vanilla maybe [declare -lib mrpeach]

Osc messages need an address.
I have put /python...... it could be /test or /anything.
The address can be longer......
You could have for example /mixer/fader1 and then /mixer/fader2 ...... the address tells the receiver how to differentiate messages on the same port.

"send" tells [packOSC] that it is a message that it should send.

If your receiver (python) is on the same computer then [connect localhost portnumber(
If it is on another computer [connect IPaddress portnumber(
i.e. [connect 192.168.1.67 9997(

David.

Hey-ho........ I just noticed you posted your patch.
I have not changed it.... I just changed the objects to their basic names and it works for me........
patch.pd
MrPeach is usually reliable sending OSC bundles in the correct format.
OSC can be sent in various formats and it can be necessary to set the format for each part of a bundle..... so for /test 0.5 hello 2 using the new vanilla objects the format would have to be set as fsi.....float symbol integer
But MrPeach does that automatically.
I have never coded in Python though.

@jaffasplaffa I think your biggest problem will be routing the info of the various parameters to the appropriate locations. I guess the way to do it might be to have a giant [route] with a counter, for each type of sysex? basically you need a state machine with a counter that counts how many parameters have been received, and changes the routing depending on the values of previous received values

if you want to do the 32-patch sysexs you will need to do some bitshifting of some of the inputs for a few parameters too.

tihs type of thing is really better accomplished in a text format I think, perhaps look into pdlua or py/pyext or pdjs.
if you use one of these you might be able to simplify things by having an array with the name of a recieve, so you can just count the parameters and send to an appropriate receive by reading the right value from the array.

another way to do it would be to have each receive follow a specific naming format (like $0-param0, $0-param1 etc.) and then look up the appropriate number in an array for the different types of sysex. Then you can just change the send name depending on which parameter is being sent using pd's built-in message formatting with $1 etc.

how did you do it with individual sysex parameters?

Here is some info on the sysex format, which I grabbed from the free Dexed Dx7 vst's github page:
sysex-format.txt

Here is a sysex file for a bass sound patch:
BASS001.SYX

After looking a bit into it, I am pretty sure it's doable, just going to take a while to completely understand it. But I think it's doable

Hi y'all,

Purr Data 2.13.0 is now available

Downloads:
https://git.purrdata.net/jwilkes/purr-data#downloads

Please report issues here:
https://git.purrdata.net/jwilkes/purr-data/-/issues

Changes

• ported Vanilla's [inlet~ fwd] argument (reimplemented to avoid stack allocation and various other problems) (Thanks to Guillem!)
• scrollbar fix for optimal zoom (Thanks Ico!)
• avoid null selectors in core where trivial to do so, gracefully handle and annotate them when/if they happen. Also added an experimental [debuginfo] object so we can output a message with a null selector (and other methods in the future good for testing)
• ported Vanilla patch for [pow~] handling negative samples in input
• ported [savestate] from Vanilla
• ported array, scalar "bang" methods
• add base argument and inlet for [log]
• add zcheckgetfn to m_pd.h for checking method signatures match before doing an end run around typedmess. This is used for the reimplementation of [inlet~ fwd]. (Thanks to Guillem for this)
• port and re-implement Vanilla's "#ffffff" syntax for setting iemgui colors. Additionally, support the "#fff" short syntax. We're not currently saving the symbol colors in the Pd file format, yet. A warning is printed about this since it means we're still storing the lossy color format. A future version will save the symbol colors, but we want to ship a few releases supporting the new syntax before making this breaking file format change.
• added "test-object" abstraction for doing more detailed testing of objects
• fixed bug where the box width was wrong when editing certain objects (thanks to Guillem)
• port "seed" method for [noise~]
• throttle canvas_motion (part 1 of 2 of getting rid of exponential explosion when moving selections)
• port [text] "sort" method
• when clicking an error link, bring the relevant object into the viewport and animate it to make it easy for the user to find
• add "-alsaadd" flag with pulse device for pulse support (Thanks to Sam!)
• fixed some alsa bugs
• ported from Vanilla: preserve phase in [clone] after [all( message, fixed a crasher
• expand and improve the type hints for errors with edge case atoms (null selectors, null symbols, "floatlike" symbol payloads, etc.)
• improvements to french translations (Thanks Joseph!)
• update pd-lua compatibility with Lua 5.4 (Thanks Albert!)
• port multi-step undo from Vanilla (Thanks Guillem!)
• initial touch support in GUI (Thanks Albert and spidercatnat!)
• zoom viewport fix (Thanks Albert!)

@liamorourke I think it will not work with sliders for example.
For the grid you are sending "set 0 0 1" so the patch sends "format siii" to format.
I did it with a message
[;
format format siii(

but it could be
[format siii(
sent into [s format]

Anyway whatever the message you are sending you can send a format message first.
It applies to the message....... not the address like /fader
David.

Two days ago I uploaded an idea for a text entry box and asked for ideas to improve it.
@ingox showed a far superior way to achieve the text handling and a recommendation to capture a click via a struct..
I've taken the liberty of using a big chunk of ingox's code.
I've added a cursor - mostly to show the box is still active
This is the result.
textentry.zip
Usage:
Click anywhere in the box to activate, the box will be cleared and the cursor will appear and flash at left side.
After typing, press 'enter' and the box will output a symbol of the text, the cursor will be hidden indicating the box is now inactive, but the text remains until the box is clicked again

Setting Up:
Messages are currently the only way to set the properties. Decide the number of characters and the font size first
Then make sure you are not in edit mode and type characters from the start until the maximum characters are reached
Now size the box so that the right side is the same as the text width, and centre the text up and down with textpos
All the other properties change at any point.

IMPORTANT:-DO NOT type a backspace in the box when in edit mode, it will delete the [textentry] object

IMPORTANT:-textentry is only suitable for monospace fonts

IMPORTANT:-always have the box width the same size as the width of the maximum characters typed or the cusor position will be wrong.

PROPERTIES
size nn (width height)
textcol n (struct rgb format 0-999)
backcol n (struct rgb format 0-999)
bordercol n (struct rgb format 0-999)
cursorcol n (struct rgb format 0-999)
fontsize n n (font fontsize)
textpos n n (left top)
chars n (max characters)
cursorwidth n
borderwidth n

Hello everyone, ive got this problem while trying to connect my arduino to Pd. Already installed firmata, used firmata test app to check its ok, and it is. But when i open the arduino-test pd patch, i get this:

netreceive: failed to sett SO_BROADCAST
comport - PD external for unix/windows
LGPL 1998-2015, Winfried Ritsch and others (see LICENSE.txt)
Institute for Electronic Music - Graz
[comport] Opening COM1
[comport]: could not open device COM1:
failure(2) ERROR_FILE_NOT_FOUND

[comport] opening serial port 1 failed!
moocow/string2any 32 -1
... couldn't create
route 13 0 20 1 (message->prepend) connection failed
route 14 0 20 1 (message->prepend) connection failed
route 16 0 20 1 (bang->prepend) connection failed
route 17 0 20 1 (bang->prepend) connection failed
moocow/string2any 32 -1
... couldn't create
moocow/any2string
... couldn't create
moocow/any2string
... couldn't create
moocow/string2any 32 -1
... couldn't create
[arduino]: version_0.5
[comport]: could not open device COM1:
failure(2) ERROR_FILE_NOT_FOUND

Firmware: 2-5.
UNKNOWN_INPUT_COMMAND: 0 480
UNKNOWN_INPUT_COMMAND: 0 479
UNKNOWN_INPUT_COMMAND: 0 479
UNKNOWN_INPUT_COMMAND: 0 480
UNKNOWN_INPUT_COMMAND: 0 479
UNKNOWN_INPUT_COMMAND: 0 480
UNKNOWN_INPUT_COMMAND: 0 479
UNKNOWN_INPUT_COMMAND: 0 479
UNKNOWN_INPUT_COMMAND: 0 479
UNKNOWN_INPUT_COMMAND: 0 480
UNKNOWN_INPUT_COMMAND: 0 479
UNKNOWN_INPUT_COMMAND: 0 480

So, i select the port im using and the A0 pin which is the one with the potentiometer im gonna use, and i get thousands of UNKNOWN_INPUT_COMMAND messages, i turn the pot and the values go from 0 to 1000, and the pd device info block has Firmata 2.5 so its recognizing the device, but cant go beyond that. Any ideas? I see that moocow is missing (and that could be relevant), but couldnt get anything using the "find externals" function.

Is it possible to parse the namespace of OSC messages in MobMuPlat?

MobMuPlat handles OSC communication in a wrapper patch that provides a message called 'fromNetwork'.

Say the OSC message is: /level1/level2/levelN format value
It has the format: [path format value]. The path here uses a namespace that subdivides according to levels.

With oscparse, the namespace in the path could be parsed like this :
netreceive -> oscparse-> list trim -> route level1 -> route level 2 ... route levelN

https://forum.pdpatchrepo.info/topic/9856/oscformat-and-oscparse-integer-not-routing-as-expected/8

With MobMuPlat's 'valueFromNetwork', is it still possible to "route" the value of the message according to the namespace? Since valueToNetwork contains a list where the first argument is the entire path, I can only split the first argument from the remaining arguments:
receive fromNetwork -> route list -> route /level1/level2/levelN

But I can't further split within the path itself to divide leve1/level2/levelN:
receive fromNetwork -> route list -> route .level1 -> route level2 -> route levelN.

Is there a way of doing this?