@esaruoho This being a new thread I had forgotten that you were using a wired USB connection.
Yes, that means that you are limited to midi only.
It will be possible to talk both ways but you will be limited to 127 steps for your controls.. so much lower resolution than OSC...... unless you use the pitchbend in TouchOSC and the [bendin] and [bendout] objects in Pd..... see below.
Also I am not sure that you can change data and colour for the same GUI through midi, but you could use 2 GUI's.... a fader and a "push" button or text label above or on top of the fader for the colour.

The 127 step resolution can be improved using pitchbend to get 14-bit resolution...... https://vi-control.net/community/threads/touchosc-has-been-updated.110551/page-3

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

So the patch I posted was for OSC wireless....... sorry.
The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).
You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......
David.

@bobpell said:

If I put it as a VST/CLAP... in one Reaper track, I don't know how to separate the single sounds on different tracks, if still possible.

Reaper allows sends to be defined based on subsets of the source channels.

2 - single parts of the project (in different Plugdata patches) opened each in a single Reaper tracks: how can I keep shynchronized them? In the whole project I have a "complex" timer that should drive each sound generation block.

DAW timeline data are available, but inconvenient to use directly. I made an abstraction, [playhead-tick], that generates whole-beat ticks from the raw timeline values, detailed in the second half here:

... using objects in https://github.com/jamshark70/hjh-abs

This way, each individual patch can know what beat it is on the timeline, and this would be the same across all of them.

When you say "'complex' timer," of course there's no way for a reader here to know what you mean. But it's possible to synthesize any timing you like from equally spaced ticks. I also have a [tick-scheduler] object in my abstraction pack where you can reschedule messages at any intervals you like (= synthesizing timing).

[playhead-tick] was originally designed as a companion to the scheduler, but later I felt that a clock-multiplier approach is easier for most cases and more idiomatic to Pd -- so the video demonstrates only the clock multiplier. (To be honest, incremental rescheduling based on time deltas turned out to be a bit clumsy in Pd -- it can be made to work but never felt to me like a natural idiom. There's an example in the [tick-scheduler] help patch.)

hjh

well
tbf the 'old guard' is slowly migrating pd away from being reliant on tcl/tk and developing a non-tcl/tk-specific gui message format so that something like gtk or qt might be used
could be done less 'incrementally' though imo.
my issue isn't so much with how dated tcl/tk is, but the general dismissiveness of its devs regarding fixing bugs/unwanted behavior.
a few years ago I was trying to get them to fix a part of the 'help' menu being disabled on MacOS and their initial response was basically 'you can work around it/maybe it's on the apple side so whatever' even though we COULDN'T work around it:
https://core.tcl-lang.org/tk/tktview/7185d26cf4121c526718459f5fd239e6d777fdee

this kind of response/attitude is frustrating to see from devs, (even though it might only be a handful/very small minority of them). And from what I've seen it isn't constrained to that issue. There's often a 'throw your hands up' attitude..

that being said, in the end they did consider it a bug and did fix it. If you want better support for high-resolution displays you can always see what the options are/what the support is like on the tcl/tk side.

but, it might be up to pd to render things differently/send different commands (and that might be the case w/ a more 'modern' framework as well) since all of the geometry is based on pixels. maybe it's possible to store some kind of flag and edit/save the window at a zoom size twice what it would be for a non-high-resolution display. When the window is saved it would store the view area as half of the current value (so the viewing area is the same on regular resolution as well). and when windows are opened they open to double the size of their saved value

Hi, I'm looking for someone with a deeper understanding of PD and audio synthesis to help me understand why my patch sounds the way it sounds. I don't know why the audio is generated this way. I don't know if it is because of some expected behavior of square waves and the math behind it, or if it is because of some quirk of PD and the way I'm generating the square wave. If you think you can help, please stay with me, I don't know who to go to or what to study to help me understand this.

I was attempting to make a square wave from scratch, I saw some tutorials and I know there are more "proper" ways of doing this, but the simplest I could think of was -1 and 1 alternating. The osc I built is a metronome with a route alternating between -1 and 1 at a given hertz. But the result doesn't sound like a single square wave, there are some harmonics, almost like having senoidal waves mixed with the square wave.

Experimenting, I noticed a cycle of the resonances going from 1hz to 1378.125hz where it completely stops, like zero hz, or one tick in several, several minutes. Other cycles multiples of this frequency exist, like this:

n=1378.125hz
Cycle0 = 1 to n* 2^0
Cycle1 = n*(2^0) to n*(2^1)
Cycle2 = n*(2^1) to n*(2^2)
Cycle3 = n*(2^2) to n*(2^2)
? Cyclen= n2^(n-1) to n(2^n) ?

C0 and C1 are very similar, with subtle differences, but inside of C2 it seems like 2 times C0 or C1 (I didn't check it, but it sounds like this). Inside C3 there are 3 times, and next, C4, 4 times, and so on, the same cycle but more times and faster in each power of two.

I have made a patch that makes it easy to clone the osc to generate each Cycle. For example, clone 10 times to get audio files from C0 through C9.

Where do the resonances come from? Why these cycles exist? Are they some kind of harmonic series? Why 1378.125hz? Is this expected from the math, or is it a quirk result of some PD object (like inputing very low numbers to the metronome)? Does someone understand why this is happening?

main_oscs_cycles.pd
square-from-scratch-osc.pd used in main
square-from-scratch-osc-lineramp.pd used in main

@cfry I used the Arduino library "OSC" by Adrian Freed and in it there are lots of Arduino examples and a few Pd examples using the mrpeach library (which I don't use anymore since vanilla started talking OSC natively). If you can give me a better sense of what you are having trouble with I can make a more helpful example, e.g. do you need bidirectional messaging? What data are you passing (if any)? What Arduino library would you prefer to use (I see there are more now than when I started)? is it over WiFi or ethernet or something else?

But maybe this example from the OSC lib is all you need: UDPSendMessage.ino

Edit: I found my knockoff ethernet shield and wrote this Arduino sender and Pd receiver,. It includes an example of how to route numbers in the OSC path. Hope this helps.
testOSCSend.ino
osc rcv dump.pd

Howdy all,

I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.

I'm just writing for myself and don't speak for Miller or anyone else.

Mac looks good

The antialiasing on macOS is provided by the system and utilized by Tk. It's essentially "free" and you can enable or disable it on the canvas. This is by design as I believe Apple pushed antialiasing at the system level starting with Mac OS X 1.

There are even some platform-specific settings to control the underlying CoreGraphics settings which I think Hans tried but had issues with: https://github.com/pure-data/pure-data/blob/master/tcl/apple_events.tcl#L16. As I recall, I actually disabled the font antialiasing as people complained that the canvas fonts on mac were "too fuzzy" while Linux was "nice and crisp."

In addition, the last few versions of Pd have had support for "Retina" high resolution displays enabled and the macOS compositor does a nice job of handling the point to pixel scaling for you, for free, in the background. Again, Tk simply uses the system for this and you can enable/disable via various app bundle plist settings and/or app defaults keys.

This is why the macOS screenshots look so good: antialiasing is on and it's likely the rendering is at double the resolution of the Linux screenshot.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.

Nah. Apple simply invested in antialiasing via its accelerated compositor when OS X was released. I doubt there are patents or licensing on common antialiasing algorithms which go back to the 60s or even earlier.

tkpath exists, why not use it?

Last I checked, tkpath is long dead. Sure, it has a website and screenshots (uhh Mac OS X 10.2 anyone?) but the latest (and only?) Sourceforge download is dated 2005. I do see a mirror repo on Github but it is archived and the last commit was 5 years ago.

And I did check on this, in fact I spent about a day (unpaid) seeing if I could update the tkpath mac implementation to move away from the ATSU (Apple Type Support) APIs which were not available in 64 bit. In the end, I ran out of energy and stopped as it would be too much work, too many details, and likely to not be maintained reliably by probably anyone.

It makes sense to help out a thriving project but much harder to justify propping something up that is barely active beyond "it still works" on a couple of platforms.

Why aren't the fonts all the same yet?!

I also despise how linux/windows has 'bold' for default

I honestly don't really care about this... but I resisted because I know so many people do and are used to it already. We could clearly and easily make the change but then we have to deal with all the pushback. If you went to the Pd list and got an overwhelming consensus and Miller was fine with it, then ok, that would make sense. As it was, "I think it should be this way because it doesn't make sense to me" was not enough of a carrot for me to personally make and support the change.

Maybe my problem is that I feel a responsibility for making what seems like a quick and easy change to others?

And this view is after having put an in ordinate amount of time just getting (almost) the same font on all platforms, including writing and debugging a custom C Tcl extension just to load arbitrary TTF files on Windows.

Why don't we add abz, 123 to Pd? xyzzy already has it?!

What I've learned is that it's much easier to write new code than it is to maintain it. This is especially true for cross platform projects where you have to figure out platform intricacies and edge cases even when mediated by a common interface like Tk. It's true for any non-native wrapper like QT, WXWidgets, web browsers, etc.

Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot. That being said, I just spent about 2 hours fixing the help browser for mac after trying Miller's latest 0.52-0test2 build. The end result is 4 lines of code.

For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.

Yes, this is correct, but first we have to keep the damn thing working at all. I think most people agree with you, including me when I was teaching with Pd.

I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.

I read this as "community" = "active developers." It's true, some people tend to poo poo the same reoccurring ideas but this is largely out of years of hearing discussions and decisions and treatises on the list or the forum or facebook or whatever but nothing more. In the end, code talks, even better, a working technical implementation that is honed with input from people who will most likely end up maintaining it, without probably understanding it completely at first.

This was very hard back on Sourceforge as people had to submit patches(!) to the bug tracker. Thanks to moving development to Github and the improvement of tools and community, I'm happy to see the new engagement over the last 5-10 years. This was one of the pushes for me to help overhaul the build system to make it possible and easy for people to build Pd itself, then they are much more likely to help contribute as opposed to waiting for binary builds and unleashing an unmanageable flood of bug reports and feature requests on the mailing list.

I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk).

A couple of points:

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years, especially since Miller's stated goal was for 50 year project support, ie. pieces composed in the late 90s should work in 2040. This is one reason why we don't just "switch over to QT or Juce so the lines can look like Max." At this point, Pd is aesthetically more Max than Max, at least judging by looking at the original Ircam Max documentation in an archive closet at work.

A way forward: libpd?

I my view, the best way forward is to build upon Jonathan Wilke's work in Purr Data for abstracting the GUI communication. He essentially replaced the raw Tcl commands with abstracted drawing commands such as "draw rectangle here of this color and thickness" or "open this window and put it here."

For those that don't know, "Pd" is actually two processes, similar to SuperCollider, where the "core" manages the audio, patch dsp/msg graph, and most of the canvas interaction event handling (mouse, key). The GUI is a separate process which communicates with the core over a localhost loopback networking connection. The GUI is basically just opening windows, showing settings, and forwarding interaction events to the core. When you open the audio preferences dialog, the core sends the current settings to the GUI, the GUI then sends everything back to the core after you make your changes and close the dialog. The same for working on a patch canvas: your mouse and key events are forwarded to the core, then drawing commands are sent back like "draw object outline here, draw osc~ text here inside. etc."

So basically, the core has almost all of the GUI's logic while the GUI just does the chrome like scroll bars and windows. This means it could be trivial to port the GUI to other toolkits or frameworks as compared to rewriting an overly interconnected monolithic application (trust me, I know...).

Basically, if we take Jonathan's approach, I feel adding a GUI communication abstraction layer to libpd would allow for making custom GUIs much easier. You basically just have to respond to the drawing and windowing commands and forward the input events.

Ideally, then each fork could use the same Pd core internally and implement their own GUIs or platform specific versions such as a pure Cocoa macOS Pd. There is some other re-organization that would be needed in the C core, but we've already ported a number of improvements from extended and Pd-L2ork, so it is indeed possible.

Also note: the libpd C sources are now part of the pure-data repo as of a couple months ago...

Discouraging Initiative?!

But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.

IMO Pd is healthier now than it has been as long as I've know it (2006). We have so many updates and improvements over every release the last few years, with many contributions by people in this thread. Thank you! THAT is how we make the project sustainable and work toward finding solutions for deep issues and aesthetic issues and usage issues and all of that.

We've managed to integrate a great many changes from Pd-Extended into vanilla and open up/decentralize the externals and in a collaborative manner. For this I am also grateful when I install an external for a project.

At this point, I encourage more people to pitch in. If you work at a university or institution, consider sponsoring some student work on specific issues which volunteering developers could help supervise, organize a Pd conference or developer meetup (this are super useful!), or consider some sort of paid residency or focused project for artists using Pd. A good amount of my own work on Pd and libpd has been sponsored in many of these ways and has helped encourage me to continue.

This is likely to be more positive toward the community as a whole than banging back and forth on the list or the forum. Besides, I'd rather see cool projects made with Pd than keep talking about working on Pd.

That being said, I know everyone here wants to see the project continue and improve and it will. We are still largely opening up the development and figuring how to support/maintain it. As with any such project, this is an ongoing process.

Out

Ok, that was long and rambly and it's way past my bed time.

Good night all.

@jameslo Yes, the removal of the symbol tag is a bind. A list can contain one symbol, but as the list tag is removed the symbol tag is not added back (flawed analysis... see below).
Passing [symbol woof( through [$1( also removes the tag.
It is a mess.......
I remembered all that after I had gone to bed.

"text" really needs to disappear as a type........ as we discussed before.... a single atom symbol needs to be always tagged as a symbol to simplify message handling.

There is a solution however......... unintuitive and without logic........ passing single atom "text" through [list] does not add the list tag....... probably because it is not true to type.....
It adds the symbol tag.......... this..pd
David.

also... <apologies to @ddw_music for hijacking topic/>
but..... <the questions raised always provoke thread deviation/>

@buzzelljason Yes. Well. Everything sent by a control rate object is a message.
The messages can be floats or symbols or lists.
Lists are a list comprising floats or symbols or a mixture of the two.
Items (atoms) in a list are separated by spaces.
It gets complicated.
If the first atom in the list is a float then the "list" tag is automatically applied, and then is silently ignored and dropped as it passes through the next object (except for [route list symbol float].......)
If the first atom in the list is a symbol then that symbol becomes the tag.... the list header..... and the list can be routed by that tag. But if the list passes through a [list] object then "list" is added (prepended) as the header. That is why [list trim] is used almost everywhere after a [list] object...... to remove the header and then be able to [route] by the original tag (if it was a symbol).

HINT.. If you install the Zexy library then [rawprint] shows you whether an atom is a "tag", 'symbol' or float....
Trying to work with vanilla OSC objects can be just guesswork without [rawprint].
mmm.pd

The messages arrive from [audiosettings] as a list which is a mixture of floats and symbols........ but the first atom is a symbol and there is no "list" tag.
[listdevices( returns a series of messages..... they are lists...... with the first atom "device"
That is why "device"....... a symbol.... and "0" or "1" can be routed. "1" could not be routed by [route 0 1] unless it is a float and "device" could not be routed by [route device] unless it is a symbol.

The device name is a symbol........ it can only be sent on in one hit because it is a symbol...... if it were a list then each part would be sent separately as a space normally "means" "next item".
But once it has passed through [route 0 1] it has lost its "symbol" tag. That can be put back by passing it through [symbol].

So the problem for [list-compare] is to create a symbol that is identical. Not easy as a message with component symbols will be treated as a list. Fortunately @ingox gave us a vanilla solution.... [concat].
And then of course to turn them both into lists for the comparison.

This will work........ this.zip
It can probably be simplified (and certainly @ingox will shortly post a more elegant solution.... ).
David.

@emviveros It could save you a lot of time if you start from the doc folder of Pd extended.
At the time of its release it had already been extensively improved when compared even to the current Vanilla doc.
Some objects will be missing of course but they can be trawled from Vanilla doc/help files.
The doc for extended was 9.32Mb..... but included 5.96Mb of media.
The doc for vanilla 0.51.3 is 2.85Mb
A difference of 0.5Mb-ish without the media...... so quite a lot of text.

It is a great idea and should be useful to everyone.
Unfortunately so many people never see the doc folder though except when they access vanilla help files and even then are blissfully unaware of its existence.

Maybe adding a "Documentation" link to the console help menu would be a good first move....?
The doc subfolder names are not enticing..... "3.audio.examples" really could be "3.digital.audio.tutorial" for example.
I don't think there is even a link to it in the "HTML Manual" which becomes "PD Documentation" when it is opened.
All very confusing though as the Pd.doc folder is mostly a patching tutorial that complements the Floss manual.

You have probably seen that @beem is working on a wiki..... https://forum.pdpatchrepo.info/topic/13054/starting-a-pure-data-wiki-database-examples-collection

Hyperlinks are the past and the future and the object help files in extended had quite a few...... although many are now dead.
David.

@Harlekin If you want TouchOSC to control OBS you don't need Pd....... just connect TouchOSC directly to the ports of osc4obs and make your remote.touchosc layout file.

If you want to do some other processing in Pd then connect TouchOSC to Pd directly (in and out)...... and then connect your processed control from PD to osc4obs directly (in and out).
osc4obs facilitates that by creating separate OSC in and out ports.
You will have to do that also if you want to use TouchOSC and Pd in an either/or situation as osc4obs only has one set of osc ports and is making a tcp connection with OBS.

OBS websocket is a tcp connection and so it is possible that osc4obs is requiring tcp for the OSC connections...... in which case remove the -u flag from [netsend] and [netreceive] in my examples below.
It could also be expecting ascii instead of binary in which case remove the -b flag (but I doubt that)....

Externals for Pd are written in C so if you are adept there is some help in Pd/doc/6.externs .....
Basically you need to make a websocket client that replicates osc4obs with outlets and inlets instead of the osc ports.

BUT... you could try the iemnet [tcpclient] first (NOT the [udpclient]...!).... and that should work.
Just replace both [netsend] and [netreceive] with the one [tcpclient]...... connect it to OBS and look at the output using a [print] object.
If OBS is on the same computer the connect message will be [connect 127.0.0.1 4444(
Remove the password from the OBS websocket unless you find that a password can be added to the [connect( message for [tcpclient]...... before or after the port number? preceded by "password" or "passwd"?...... guesswork...... and [tcpclient] might well not accept a password as it is not mentioned in the help file.
Once you are looking at a print of the received messages the problem will be to decode the proprietary message format (it will not be OSC)....... it might be easy.... or not.
If lucky there will probably be the ascii strings you are looking for or a decimal representation of them somewhere in the message.

If you go the osc4obs route then it is quite easy to use [oscformat] and [oscparse] in vanilla instead of creating an external.......
...... vanilla osc.zip

P.S. try to avoid integers within the OSC address (header) as they arrive in Pd as symbols at the output of [oscparse] ....... and are then difficult to route. So what/ever/6 data is best avoided if possible and what/ever/six data is easier to deal with in Pd...... but I have included a solution in the zip file above.

Be careful in TouchOSC to avoid message feedback (much like midi feedback)......... and the same applies in Pd. In Pd you can include "set" at the start of a message (without the quote marks)...... which will set a message in the next object or message box but not send it onward until that object or message is banged.
David.