@ingox "I would consider the solution with [route] as elegant and the way to go"
Thank you! So I'm not missing anything obvious
@jancsika Good summary, thanks.
@whale-av "Pd is all about messages...... and so it is all about lists"
Right, I understand arrays. (In SC, array elements are just references to objects rather than a fixed data types, so, like pd lists, each element can be a different type --
['selector', 4.0]is valid as both an SC array and a pd list.) I haven't spent enough time with pd's list manipulation objects, but I will have to, soon.
list-abs is a good tip, thanks. Seems to have a lot of equivalents of SC's array operations ([list-add] = array1 + array2, [list-drip] --> Pseq(array, 1).asStream).
You can also sort by position in a list...... by undeclared index.
That one is beyond me at this point.
The real difference of data flow programming is that it is always 'running'. So mistakes are seen straight away which is a huge advantage for us noobs.
Hm, signal processing is always running, and GEM is always running, but messages are running only when something is triggering them, right? If I "play" a Routine in SC, then that is always running (until stopped), not really any different from a pd object graph triggered periodically by [metro].
I think what's more approachable about data flows is that a patch cord on screen is "concrete" in a way that function arguments in code are not. (But I'll still use SC for my own work because I find it easier to scale up to high complexity.)
I've made a vanilla [gate] but you also need [initbang] (another dependency) to make anything with a dynamic number of outlets at creation time.
Cool, interesting. I went to your github link and found there is a signal [gate~] but I don't see the one for [gate].
My main reason for asking is about the methodology. I'm a long-time SuperCollider user, now considering PD for an interactive multimedia course that will begin next spring, for a couple of reasons -- a/ while I think SC is better able to handle complex requirements, the code frightens students who don't want to think of themselves as programmers (even though data flow programming is programming, with the boxes and wires, I can lie to them and they'll believe it), and b/ SC doesn't have built-in video capability (and I really hesitate to make the class SC + Processing, one programming language is already too much).
I use SC because I "get" code in a way that I don't naturally "get" data flows. So I'm asking how I should think about this programming task -- one data source, fed out to one of several paths that can be dynamically selected. In SC, if it's "language-side" processing (analogous to pd simple messages), I would use a
switchstatement or a collection of functions; if it's signal processing, I would use PanAz (multichannel panner).
I could imagine [prepend]-ing an index number onto the value to pass through, and then using [route]. But I'm not fluent enough in data flows to know if this would be considered "elegant" or "kludgey."
If I don't want to incur a dependency on cyclone, how would I do the equivalent of [gate]?
I find that I need this very often, but I don't see it in the core objects. (Or, if I need it fairly often and Pd doesn't need to provide it, then maybe I'm thinking about the signal flow in the wrong way, and there might be another way to structure things.)
For example, if I have some control data and I want to switch between three different calculation paths, my instinct is control data --> [gate] --> 3 outputs. But maybe there's another way?
In Firefox + Ubuntu Studio + dark screen theme (blackbird), the post editor has a dark background and a dark font color.
When you use a dark screen theme, you find a LOT of websites with broken CSS this way -- either the font color is specified dark, but the background color is left default (becomes dark from the system theme), or the background color is specified light and the font color takes the system default (light).
Should be an easy fix.
This is probably a pretty basic question.
I've avoided interactive graphics for a long time, but now exploring GEM for a class about nine months down the road. (Actually, I've used GEM for some basic webcam analysis, but that project didn't involve any geometry or texture mapping.)
So I created a [gemhead] --> [pix_image] --> [pix_texture] --> [rotate] --> [translateXYZ] --> [sphere] patch (with a bunch of sliders to mess around with the rotation and translation, and a line generator to act as a phasor for rotation angle). With that, I get the image spinning around the sphere and the sphere's position rotating around some axis.
Then I reversed the rotation and translation: [gemhead] --> [pix_image] --> [pix_texture] --> [translateXYZ] --> [rotate] --> [sphere]. In this arrangement, the translation parameters affect the position of the sphere, but the sphere is stationary and the rotation angle affects only the image mapping.
I would have expected: translate first, then rotate, would offset the sphere away from the rotation axis and then the rotation would affect position. Likewise, rotate first, then translate, would rotate the texture mapping and then position the sphere according to translation.
But I get the opposite. So, I'm not understanding something -- either about the order of operations, or the way that the operations are applied.
I have a feeling the answer to this question will take me several steps further -- best to get these concepts right at the beginning.
I was just trying to use [midiout] to send clock messages (to test a MIDI sync clock in other software).
I've already verified that Pd's ALSA MIDI project is connected to SuperCollider's input port. I can send note messages out of Pd and SuperCollider receives them. So there is no communication problem. (Linux btw.)
The only documentation says that [midiout] sends raw MIDI. So I looked up the clock messages in the MIDI spec:
11111000 = 248 = tick
11111010 = 250 = start
11111100 = 252 = stop
I'm sending these numbers to the left inlet of [midiout] and exactly nothing is happening in SC.
- MIDI communication Pd --> SC is working.
- I already set up the
MIDIIn.sysrtfunction in SC.
So I have to conclude that my input to [midiout] is wrong.
However, I can't possibly figure out what the input should look like based only on the phrase "raw MIDI."
Can anyone clarify?
@whale-av thanks for the tip. I had tried a deken download yesterday, but that didn't work either.
Then I found https://github.com/reduzent/pd-mrpeach, which seems to be the version of the sources used for deken.
cd pd-mrpeach/net && makegives me a slew of .pd_linux files. But, after that, all of the following still fail:
- path4: /home/dlm/share/pd/pd-mrpeach
- path4: /home/dlm/share/pd/pd-mrpeach/net
- [import mrpeach]
- [import mrpeach/net]
So it seems mrpeach is now a dead library, unless somebody else has other advice. If that's the case, it should probably be removed from distributions. It's misleading (and really quite frustrating for users) to have a "mrpeach/" entry in the help browser when you can't use it.
So my remaining alternatives seem to be:
I think I'm only using the OSC objects from mrpeach. Somebody else just told me that there are core objects now for OSC. (I'm pretty sure when I created the patch before, mrpeach was recommended but perhaps the core objects have improved in the last, ummhhh, 5 years lol.)
If all else fails, now I see there's purr-data.
Thanks for the help!
"/usr/lib" is a standard Linux path. I would expect C: to confuse Pd when running in Linux.
But, omitting C: and having "flags: -lib /usr/lib/pd/extra/mrpeach" in .pdsettings, I still get:
cyclone: can't load library
mrpeach: can't load library
/usr/lib/pd/extra/mrpeach: can't load library
[import mrpeach] says:
written by Hans-Christoph Steiner firstname.lastname@example.org
compiled on Jun 17 2011 at 10:45:22
compiled against Pd version 0.43.0
[import]: ERROR: can't load library in mrpeach
I appreciate the abstractions, and I might try them later.
I can't shake the feeling that something is fundamentally broken about library loading in Pd. My main audio programming platform is SuperCollider. In SC, I can go to Preferences > Interpreter, click [+] next to the box for include paths, add a directory, exit preferences, then Language > Reboot interpreter, and the new classes are there. I think it's a reasonable assumption for Pd to be able to go to Edit > Preferences > Path and > Startup, add a directory which actually exists in the file system and which contains Pd objects, and it should work.
^^ This page appears to claim that all libraries under /usr/lib/pd/extra will be loaded, or at least available for loading. That is not happening.
I've also seen the online that many other people have had the same problem. So, if in this thread we can find a proper solution, then we can help many people instead of just working around it.