@whale-av This is really terrific. I did not know about cxc_split. I also see the value of placing an enitre string in a message for programming and debug purposes. I'll let you know if I figure out why that error is bring logged in the console.

Thanks again,

Matt

@whale-av Hi David,
Wow, so clean and efficient! It works wonderfully except for one problem, the patch doesn't seem to like negative values for "pitch" and 'yaw". I notice a forward slash in the console, at the end of the "pitch" and yaw' values. I'm assuming that it's truncating the decimal places at a certain point.

Here's a complete message, with negative values:
34 102 111 118 34 58 57 48 44 34 105 100 34 58 34 107 101 100 34 44 34 112 105 116 99 104 34 58 45 49 46 49 51 49 56 53 53 54 48 55 48 51 50 55 55 53 57 44 34 112 111 115 105 116 105 111 110 34 58 49 50 53 50 56 57 44 34 114 111 108 108 34 58 48 44 34 115 116 97 116 101 34 58 50 44 34 117 114 108 34 58 34 102 105 108 101 58 47 47 47 85 115 101 114 115 47 108 97 112 116 111 112 111 108 105 115 116 47 68 101 115 107 116 111 112 47 86 101 103 97 115 46 109 112 52 34 44 34 121 97 119 34 58 45 50 46 51 49 51 57 50 55 49 55 51 54 49 52 53 48 50

Thank you for your time with this!

Regards, Matt

@whale-av Hi David,

I see where you're going, and I'm trying something similar parsing with [list split], and using [list length] of the entire message, subtracted by the [list length] after each parameter. It sorta works, but I'm running into issues.

Anyway, as requested, here is a complete message. I've gone ahead and parsed it, to make it easier on the eyes.

print:
123
34 102 111 118 34 58 56 52 44
34 105 100 34 58 34 107 101 100 34 44
34 112 105 116 99 104 34 58 48 44
34 112 111 115 105 116 105 111 110 34 58 57 51 52 51 44
34 114 111 108 108 34 58 48 44
34 115 116 97 116 101 34 58 50 44
34 117 114 108 34 58 34 102 105 108 101 58 47 47 47 85 115 101 114 115 47 108 97 112 116 111 112 111 108 105 115 116 47 68 101 115 107 116 111 112 47 85 108 116 114 97 70 108 105 103 104 116 46 109 112 52 34 44
34 121 97 119 34 58 48
125

Thanks, Matt

Hi There,

I've made significant progress with the patch, using my initial concept of connecting [route] serially. I have a few problems still to address.

I'm currently connecting sub patches for each parameter serially, which works but is less than ideal.

• Using this approach means that the URL sub patch will need to be manually redone for each video, on each computer.
• Data stops flowing past the pitch parameter whenever it's at a -0 value. -1, -2, -3, and positive values are all okay, but not -0.
• The position parameter is counting in ms., which cause parameters down the line to stutter.

The fix for all of this would be to access each parameter directly from [udpreceive]. I've tried a few of the list-abs objects, but have not gotten anything to work yet.

Attached is an overview of the patch and the fov sub patch.

Okay, I just realized I can replace the [pd fov_decode] subpatch with [bytes2any]. That cleans things up a fair bit, but doesn't solve the problem of needing to continue serializing [route]. It seems logical to me that there would be a way of going directly from [udpreceive] to the parameter I want to decode, instead of needing to cascade from fov to pitch to yaw, etc... Is there an object I'm not familiar with that will allow this?

Matt

Hi Friends,
I am streaming fov, pitch, yaw, roll, position and other parameters in the form of ascii strings, from the GoProVr Video Player. I am parsing the strings using a series of [route] which then get fed into [float2ascii] and [json-decode]. This works reasonably well until I run into situations where a string changes from let's say 2 characters to 3 or more. When this happens I need to use [unpack] for the max number of characters. The independent characters are combined to a single number using various [expr], while [spigot] and [switch] allow me to choose a different [expr] and number atom, based on the number of characters being generated.

The problem comes when I try to move on from one parameter (fov) to let's say (pitch), because I can no longer serialize using [route], as the values can not be known in advance. I wouldn't mind being able to truncate the pitch and yaw values, as well.

Here's an some example data using [bytes2any]:
print: "fov":90
print: "id":"ked"
print: "pitch":0.036522697657346725
print: "position":45600
print: "roll":0
print: "state":2
print: "url":"file:///Users/laptopolist/Desktop/UltraFlight.mp4"
print: "yaw":-0.09542924165725708

I've also included an abstraction that demonstrates what I'm doing.
fov-example.pd

Thanks, Matt

Hi Friends,

I'm looking to get the pitch & yaw coordinates from the GoProVr Player which sends messages in JSON format. I see the messages coming in as numbers using [udpreceive 8000], but I'm unable to parse via [json-decode], followed by [list trim] and [route id yaw pitch]. The best I can get do is print a stream of "123" from [json-decode], [list trim], or the last outlet of [route].

http://www.kolor.com/wiki-en/action/view/GoPro_VR_Player_-_UDP_Communication

Any thoughts would be greatly appreciated.

Thanks, Matt

JSON.pd

Hi David,

Dang, I knew it was something simple. Thanks so much!

Matt

Hi Folks,

I've made a simple Karplus Strong synth that I'm trying to control via [notein] to a [mtof]. The problem is that the higher the MIDI note number the longer the delay time, which lowers the pitch... To remedy this, I need to invert the MIDI note numbers. For example, if you play MIDI note number 60 (C3), you want to output note number 67 before hitting the [mtof].

I can use the [select] object to convert a range of numbers to select the inverted number, but this is not practical to do implement for 128 numbers. My next thought was to use a slider with a range from 127 - 0, thinking there might be a way for the input number to be seen as an index that the slider would read from bottom to top, but that is not the case.

Granted, the synth is only usable within a range of ~3 octaves, but I thought I might as well make an abstract that includes the full range. Any thoughts?

FYI - dividing the frequency output by the [mtof] object by 102.5 was all that was needed to tune the delay time

Thanks,
Matt

Hello David,

Thanks again. You've been really helpful.

Matt