Hi,

I'm stuck on what must be a simple problem, but I can't seem to figure it out.

I have a number - a GPS coordinate - that I am trying to split into Hours/Minutes/Seconds.

Lets say the number is 45.4388.
I can get the '45' and the 0.4388 easy enough by using a [trigger] , [int] , and [-] object. Eg.

[45.4388\
|
[t f f]
| |
[-] _
| |
[45\ [0.4388\

Now what I'm trying to do is parse the Minutes (43) and the Seconds (88), but I'm stuck on how to do that.

I've messed around with a list, trying to unpack it, a route object, etc with no luck.
One caveat that I should mention is that these numbers change frequently, so I can't do any pattern matching with stored values, like the route object would do, etc.

Also, it would be preferable for this to run in Pd Vanilla (though I can deal with it if not).

Thanks in advance...

~ Jesse_

I have a patch that is reading a text file (converted from gpx), and parsing it out in order to drive sound synthesis.

I'm using both snapshot and a tabwrite to visualize the two different synth chains (one driven by latitude + altitude, the other by longitude + altitude), and can see that the numbers are ranging a lot - from 0 to 120 or so... which is expected, and no problem.

The problem is that writesf~ is only seeming to take the values when they exist between 0 and 1, so only a small portion of my patch is actually recording. At least, this seems to be the issue, as far as I can tell. Can anyone confirm this behaviour ? Is there a way to edit it?

I've tried to put both a clip~ and tanh~ on my signal chain before writesf~, but they both seem to just ignore and values over the argument, and not actually compress/remap the values. Again, am I reading this behaviour correctly?

I can of course decrease the signal, but as I have several different files in my patch, and they all give different values, it is difficult to come up with an absolute value that wont unnecessarily make some of the tracks/processes sound too quiet...

None of this is a problem as far as actual playback is concerned, so in the end I might just record the output with Wiretap or some screencapture software, and just rip the audio, but I had never used writesf~ before, so thought I'd give it a try.

I might also be interested in trying soundfiler, but I am currently writing to 3 different arrays, and it doesn't seem possible to combine multiple arrays into one soundfiler write thread... but please, let me know if you have experience otherwise.

thanks for any feedback...

~ J

hi board.

i'm parsing a large text file, and am wanting to get at a particular number value,
but it is saved as...

[0:00:0$ \
(( thats supposed to be a number box !? ))

... which I can only access if I parse it with...

[symbol $x <
(( thats supposed to be a message box !? ))

... I am unsure as to how I would go about trimming/parsing the values in a symbol(atom) in order to get at the final value (or final two values) of the string (is it a string ?? )

Hope that makes sense, hope somebody can point me in the right way...

xo

j

I'm having the same issue - from some research, it seems like the native DLL's for Windows haven't been compiled properly for Windows.

Currently looking at this: https://github.com/bgbotond/libpd

Any hints on how to do this in Vanilla Pd? I'm using libpd, and it doesn't have access to the externals (unless I compile them, which I could, but...)

Awesome, thanks. That makes total sense that it would be a modulus object, now that I think about it!

hey sensn... thansk for the reply.

nice trick, never thought of that! totally works.
still interested in any other solution, as I feel that there are objects for this that I am missing...

~ J

Update... check Vade's Dropbox link in that forum thread, he provide's a binary for a simple server. We got it working here at the Pd Berlin meeting!

Vade recently updated a basic implementation, you can see it on the trunk:

http://code.google.com/p/syphon-implementations/source/detail?r=125

And there's a thread on the Syphon Forum here:

http://forums.v002.info/topic.php?id=27

@Maelstorm said:

@JesseScott said:

The problem is that writesf~ is only seeming to take the values when they exist between 0 and 1, so only a small portion of my patch is actually recording. At least, this seems to be the issue, as far as I can tell. Can anyone confirm this behaviour ? Is there a way to edit it?

I think a 32-bit float format should allow values greater than 1, but I don't know if [writesf~] will clip it anyway.

Ok, i'll try adding the -4 flag to make it 32-bit... will advise.

@Maelstorm said:

I've tried to put both a clip~ and tanh~ on my signal chain before writesf~, but they both seem to just ignore and values over the argument, and not actually compress/remap the values. Again, am I reading this behaviour correctly?

Probably not. [tanh~] doesn't take an argument, and everything should just be in the -1 to 1 range. [clip~] takes two arguments (a minimum and a maximum). Anything outside the range will be clipped within the range.

Yes, I know that tanh~ doesn't take an argument... but if I take a snapshot~ of the signal right before the tanh~ I can see that anything coming into it above 1 isn't passing through tho the dac~ ?!?

@Maelstorm said:

I can of course decrease the signal, but as I have several different files in my patch, and they all give different values, it is difficult to come up with an absolute value that wont unnecessarily make some of the tracks/processes sound too quiet...

Why not decrease them individually? Couldn't you just divide by 120?

It's just tedious... i have almost a dozen files, and I would have to either code something that stores the highest value or watch each one individually to see what the peak is for each one...

@Maelstorm said:

None of this is a problem as far as actual playback is concerned...

I find this a little hard to believe. If you're sending the same signal to the [dac~] as you are to [writesf~], they'll clip the same way. Anything outside of -1 to 1 will clip and distort.

It had me confused too, once I sat down to think about it. Sure, im getting wildly oscillating sonic values, but that's the intention...