@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

Hello David,

Thanks you for sending the patches. I am now able to get things working locally and between 2 computers. I'm impressed with how little latency there is. I've just now modified my patch to send a message as TCP over port 9001 and that also works.

Can I ask, what are the deciding factors for using UDP vs TCP? My guess is that I'll want to use TCP so I can identify and parse the multiple streams of data.

-Matt

Hi Folks,
I'm starting work on an installation that will use network data from things like card access use, temperature, hvac settings, electricity usage, etc...

To get things started, I've been trying to get netsend and netreceive to work between 2 Macs. I'm using Network Utility to see what ports are in use, and although I'm able to send successfully using a few of them, I am unable to receive. So, a couple of questions...

Are netsend/receive the right objects for me to be using in the 1st place?

Should I be creating my own port somehow or looking for a specific port that's already being detected by my system?

I've tried turning Firewalls off on the computers, and also made sure that PD is allowed to communicate.

Thanks, Matt

Hi Gilberto,

I noticed one flaw in the original patch you sent me that caused the current preset to be overwritten by the previous preset as soon as you touched a fader. I've figured out a fix, but was wondering if you see a simpler or more elegant approach.

Thanks, Matt

save_v2.pd

@gsagostinho Once again Gilberto, Thank You!!! I see now that the distinction between a subpatch and an abstraction is an important one. I'm taking your advice and converting the abstractions to subpatches, so that all of the data gets saved with the main page.

This is my first serious Pd project, and so your guidance has been a tremendous help.

Best, Matt

@gsagostinho Hi Gilberto,

Yes, I thought that I was getting a stack overflow. I will implement what you've suggested.

To better explain the second issue, I included a patch in my original post called 16_Purple_Faders, which is only one of several subpatches (abstractions?) that are called into the main patch. Although I can write to the patterns from the main patch, I am unable to save the contents of the subpatches unless I open and save each one individually. So my question is is there a way via a script, object or additional subpatch that would allow me to save all of the subpatches being used by the main patch?

I've included a simple example that will hopefully clarify things. PurpleAndOrangeFaders.zip

Thanks, Matt

@gsagostinho Hello Again Gilberto, Your approach to saving presets is working great, but I have 2 questions that you may be able to answer.

Is there a way to update the sliders when a new preset is loaded? Everything I've tried ends up creating a loop and freezes the patch. I thought I saw an object somewhere that makes a hot inlet cold (or perhaps it was a dream). Anyway, this would allow me to send the updates to the sliders without that data being sent to the slider's outputs.

The second thing is, is there a way to save all of the abstractions from the main patch, instead of opening them one by one and saving them individually? I'm using 9 abstractions, so it's a bit of work to save (and remember to save) each one.

Best, Matt

@gsagostinho Many Thanks, Gilberto. This more or less makes sense to me. I don't mind the idea of saving the patch each time, in fact, I think it's a plus.

I'll let you know how it turns out.

Best, Matt

Hello Folks,
I've got a patch that combines multiple 16 step sequencers to control an SN76477 synth on a chip, via an Arduino. There are separate sequencers for each of the synths parameters: Pitch, LFO Rate, Noise Color, Tuning, Attack & Decay, plus a few logic sequencers for controlling "mix" and pulse wave duty cycle. Each sequence is written to its own array. Things are working quite well so far, and I'd like to take the patch to the next level, which is to be able to recall up to 16 sequences per parameter, For example, the Pitch sequencer would be able to recall up to 16 different sequences. These sequences, along with sequences for the other parameters, could then be strung together to create an arrangement.
The problem is I'm not sure where to start. I've been searching using terms like "save & recall array", but haven't found anything that fits. Anyone have any ideas? To keep things simple, I've attached the abstraction for the Pitch Sequencer. Let me know if I should upload the whole patch, with the many abstractions for this to make sense.

Once I have all of this sorted, I plan on sharing the patch along with the Arduino code, and hopefully a PCB layout for the synth.

Here's a quick video of the patch in action:

16_Purple_Faders.pd

Thanks, Matt

Hi There,

I get the same errors on my Mac Pro running OSX 10.9.4. Turning off my Apogee Ensemble fixes the problem. Things seems okay though on my MBP 10.8.6 and MOTU Ultralight mk3 via FireWire.

Matt