Hey guys, havent used PD since a while and not really fluent in it, I am bit lost trying to port a working Max patch to PD. Its basically a simple Audio-Input-To-OSC patch. The Max patch works fine and sending data to Processing. But I cant make it work with PD. Does anyone see the problem as pictured below? Thanks a lot

PS: I am using PD Extended 0.43.4, but that shouldnt be a problem right?

Heres the PD patch:

Heres the Max patch:

@Smartronics Extended still works perfectly as ever.
Your patch should work if you just bang the [connect 127.0.0.1 7400( message, and [connect localhost 7400( works as well. You should remove all the other objects and messages on the right side. The [route text] object is stopping the connect message from getting a bang.
Here is a test patch for you...... if it works then you should be able to see why yours doesn't...
osc_routing.pd
P.S. is audio turned on?
Connect a [print] object to outlets of objects/messages/etc to see what messages are getting through.
David.

Hey David, thanks for your quick reply, but I am afraid, I cant make it work. Yes Audio/DSP is on, I can hear myself and see it via the VU Meter. You are saying I dont need all that stuff on the right site? Like I said I just ported a Max Sketch which worked fine. But not quite sure about PD. I downloaded it somewhere a while ago. You think some of the stuff within the patch doesnt make sense? Especially that stuff on the right?

Old
Audio-Input-to_OSC.pd

My try
Audio-Input-to_OSC_latest.pd

Thanks

@Smartronics I had not spotted the error on the left side..... sorry. The stuff on the right was unnecessary and wrong for Pure Dara.
Yes, it is always best to post the patch.
You cannot have spaces in Pure Data [prepend] as the second "argument" is invalid, so [prepend send /trigger] will only prepend "send" and /trigger will be dropped.
Here you go..........
sender2.pd
and you can also do it like this where the $1 variable is replaced by your value......
sender3.pd
other errors fixed (maybe not all !!)
sender4.pd
more errors (differences with max) fixed....
sender5.pd
David.

Hey David, thanks a lot, especially for all the examples. Everything works fine now. I also got rid off the "/trigger" and its related objects, I probably just need the volume data. I connected it to Processing and it works fine, just find a way to scale things now. One thing, when I turn off DSP, Processing is getting negative values. Why is that? I mean shouldnt it get nothing? When I disconnect the oscx obejct, processing gets nothing and stops printing values. Its a bit weird and I dont get why this is happening!?

Thanks

@Smartronics Ah!...... yes, the -99 at the bottom of the meter fooled me, and I forgot that "no output" is actually -199.....

It will still keep sending -0.00 though, so if your ranges are now set to your satisfaction it would probably be best just to use a [spigot] to stop the messages when the dsp is off.
[r pd] receives messages from Pd, and they can be filtered and routed like this......... sender6.pd
David.

no prob and thanks for letting me know, but do you think thats a good idea with +199? I mean -60 is almost silence, so wouldnt it be better to scale it with autoscale or something else to get better results? I was looking for an object to scale the value which are coming from the vu-meter to a new number that is more useful for my project. I came across autoscale and implemented it into the patch. What you think?

@Smartronics No, 199 is not necessarily a good idea.... I was just admitting my mistake.
If [autoscale] works for you then it is a good idea!
But it will output "1" straight away with it's first received input, before is finds it's max/min. You could try sending the message [load -60 1( by a loadbang to it's left inlet so that it starts with the (an) expected range...... and so in a more gentle fashion. (an initial range of -60 > 1 is a guess!).
David.

mmhhh, not quite sure what you mean with "message [load -60 1( by a loadbang to it's left inlet so that it starts with the (an) expected range...... and so in a more gentle fashion. (an initial range of -60 > 1 is a guess!)."

Could you please explain it again

thanks

@Smartronics When the [autoscale 0 1] object is created the very first input it receives will give an output of "1" and as it receives lots of different values it will make the range of those values fit the range 0 >1. If you want it to output 0 > 1 relative to the expected range of input you can give it an initial range with the load( message.
Sorry, it is a bit hard to explain....
[autoscale 0 1] will give the following values (approximately?)
0 >> 0
0.0001 >> 1
6 >> 1
3 >> 0.5
20 >> 1
10 >> 0.5
but with a [load 0 20( message received before the start it will give..
0 >> 0
0.0001 >> 0.000005
6 >> 0.3
3 >> 0.15
20 >> 1
10 >>0.5
which is more like what you might expect, an (sort of) a softer start.
Also, as you increase the input, without the load message, you will get a whole stream of "1"'s.
David.

ah ok, got it now, thats a great way of scaling and I didnt know that I could do it like this, thanks a lot

so basically like this here, right? (please see photo)

load -50 0 .... message

goes directly into the left inlet of autoscale, then I can adjust it according to the input or the desired goal? right?

@Smartronics Yes....... if you right-click [autoscale] and click help then you have some more info. The same is true for most objects and externals.
You can also fix the range with a "0" to the 4th inlet.
David.