[Sel x] - Order of operations
Could maybe someone explain the order of operations of my [sel] objects on both left and right. 1473000944963-1-working-2-not-working.pd Eventually, I want them to do the same thing, but 3 examples work very differently. (1) Works perfectly (2.1) and (2.2.) do not work in the same way as (1) does, although I am only omitting a few things, and without them I think it should still work in the same way.
I am new to PD, so I really want to understand everything that's going on, and I think that if I don't it will harm my future patching.
How to create multiple objects at once? Many objects with increasing arguments?
@lacuna I am about to be away without internet for 3 days...... so...... I will describe how it works and post another example....
Each object that you create in the subpatch has a reference within Pd...... a number... which depends on the order in which they are created..... so.....
Your 123 objects will have numbers 1-123..........
But you want to add some other objects. If you add an [outlet~] or [*~ 0.3] before you add your abstractions then that will be object 1 and your abstractions will be objects 2-124. You must be rigorous about the order in which you place the objects.
In this example......... example.pd There are already 3 objects placed in the sub-patch...... open [pd mixer_final] to have a look.
The patch then builds the objects and connects them.....
There is a [loadbang] to say how many of each object should be created, and that creates a [matrix~] with the correct number of inputs and outputs.
Lots of error messages appear in the terminal because the rest of the patches are missing... it does not matter for this example.
The [connect( messages are formatted like this..... [connect "object number" "outlet number" "object number" "inlet number"( and the inlet and outlet numbers are counted from 0-n...... first one "0"......
I do hope that is all makes sense!
Hit the bang at the top of the patch to see everything created in the sub-patch......
pd-msg in Pd vanilla
Coming back to PD after a long hiatus. I'm trying to learn how to do dynamic patching with the built-in internal messages, but the old examples don't seem to be working properly.
I copied the pd-msg folder from PD-extended and added to my PD vanilla (0.46.7) "path" (the one in Program Files/Common Files/PD)
I saw that the folder loaded in Pd's 'browser' and started going through all the examples. As I went through I noticed some worked fine, while others gave me error messages in the console. All examples work fine in PD extended (0.43.4)
Is there updated documentation on dynamic patching/internal messages in PD vanilla? do the pd-msg examples only work in PD-extended?
GPIO RASPBERRY P3 AND PURE DATA
@sylvain Hello Sylvain.....
I have to admit to being unsure.....
Wiring Pi allows you to address the pins, and there is a webIOpi web interface that allows remote control of the pins (switching them from out to in) and a serial control page that (presumably) can communicate with the uart......... but........ I am not sure that it has ben updated for the pi3.
You can find an external for Pd that claims to talk to the pins from Pd here.......
and there is a (very) short conversation on the pdlist about this........
https://lists.puredata.info/pipermail/pd-list/2013-04/102172.html which suggests that wiringPi is necessary.
Millers coding of Pure Data for the Pi (which contains an object for talking to the gpio pins) can be found here......
and there is some very useful discussion that points to that here.............
The post suggests that Pd-L2Ork could be a more useful version of Pd for you.......
My Pi is working well with dmx lighting control through a usb interface in Pd (using comport) and I control the GPIO pins through an Android remote app for my home entertainment........
But for PD to gpio I am unfortunately a noob......
gui externals tutorial ?
"make install" does not seem to install anything so I added object files manualy
It compiles but the linker cant seem to find pd stuffs although it is linked with pd...
cc -I"D:/WORK/DSP/pd-0.46-7/src" -Wno-unused-parameter -DPD -DVERSION='"0.0"' -O6 -funroll-loops -fomit-frame-pointer -Wall -W -g -o "src/adsr.o" -c "src/adsr.c" cc -rdynamic -shared -L"D:/WORK/DSP/pd-0.46-7/src" -L"D:/WORK/DSP/pd-0.46-7/bin" -o "src/adsr.dll" "src/adsr.o" libCicmWrapper_la-ebox.o libCicmWrapper_la-egraphics.o libCicmWrapper_la-eclass.o libCicmWrapper_la-eobj.o libCicmWrapper_la-ecommon.o libCicmWrapper_la-epopup.o -lpd libCicmWrapper_la-ebox.o: In function `ebox_dosave': /cygdrive/d/WORK/DSP/CicmWrapper/Sources/ebox.c:819: undefined reference to `s__X' libCicmWrapper_la-ebox.o: In function `ebox_properties': /cygdrive/d/WORK/DSP/CicmWrapper/Sources/ebox.c:1098: undefined reference to `s_symbol' /cygdrive/d/WORK/DSP/CicmWrapper/Sources/ebox.c:1113: undefined reference to `s_symbol' libCicmWrapper_la-eclass.o: In function `eclass_attr_getter': /cygdrive/d/WORK/DSP/CicmWrapper/Sources/eclass.c:639: undefined reference to `s_float' /cygdrive/d/WORK/DSP/CicmWrapper/Sources/eclass.c:653: undefined reference to `s_symbol' libCicmWrapper_la-eclass.o: In function `eclass_attr_setter': /cygdrive/d/WORK/DSP/CicmWrapper/Sources/eclass.c:753: undefined reference to `s_float' /cygdrive/d/WORK/DSP/CicmWrapper/Sources/eclass.c:775: undefined reference to `s_symbol' libCicmWrapper_la-eclass.o: In function `eclass_addmethod': /cygdrive/d/WORK/DSP/CicmWrapper/Sources/eclass.c:240: undefined reference to `s_float' /cygdrive/d/WORK/DSP/CicmWrapper/Sources/eclass.c:252: undefined reference to `s_symbol'
gui externals tutorial ?
so I think the linker should be set to -lCicmWrapper but I got conflicts and undefined
can you help me out ?
cc -rdynamic -shared -L"D:/WORK/DSP/pd-0.46-7/src" -L"D:/WORK/DSP/pd-0.46-7/bin" -o "src/adsr.dll" "src/adsr.o" -L"D:/WORK\DSP/PD/CicmWrapper-camo-dev/Sources/.libs" -lCicmWrapper -lc -lpd D:/WORK/DSP/pd-0.46-7/bin/pd.lib(pd.dll):(.text+0x0): multiple definition of `error' /usr/lib/libc.a(t-d000927.o):fake:(.text+0x0): first defined here D:/WORK\DSP/PD/CicmWrapper-camo-dev/Sources/.libs/libCicmWrapper.a(libCicmWrapper_la-ecommon.o): In function `epd_add_folder': /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:578: undefined reference to `sys_searchpath' /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:603: undefined reference to `sys_staticpath' /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:603: undefined reference to `namelist_append_files' /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:609: undefined reference to `sys_staticpath' /cygdrive/d/WORK/DSP/PD/CicmWrapper-camo-dev/Sources/ecommon.c:609: undefined reference to `namelist_append_files'```
@Mdns Hello again....
When you say switcher.pd won't work do you mean it shows a red box. It works for me just fine (I know that doesn't help!)............
But you will always need to upload any abstractions that you have created that are used in your "master patch"
You will see that the easiest way to do that is to make a zip folder of all of the necessary bits and upload that.
It seems that you are still having "path" problems. They are probably the most common problems along with getting audio to work properly.
Now that you have found (I hope) where all of the patches you had made had been hidden.... make a folder on your desktop and copy them there..... do NOT have any spaces in the folder name!!
Then open (from the menu at the top of the main (Terminal) Pd window...... select "Edit" "Preferences" and you will see a pop-up window like this.......
Add the "path" to your new desktop folder and click apply/ok. Close the window, open it again...is your path still there? It's a bit temperamental...... probably restart Pd and check again
Hopefully now everything in your new folder will work (your patches) and most of the Pd objects as well, and all subfolders that you create inside your new folder. If you add C:/users/xxxx/desktop to the paths then any pd patch on your desktop should work.
When Pd opens some of its paths are not active (/extra/mrpeach for example). You can force Pd to find the objects in that folder by putting an object into your patch.... [import mrpeach]. Anything in that folder will then work......
You can also include the path to the object in it's name...... [mrpeach/dumpOSC xxxx] for example.
Let us know how you get on....... whether that helps or whether you still have problems...
Need help to slightly modify a PD project (Rythmboy)
I'm pretty serious about getting this patch up and running. Until now, while discovering the patch and finding out how it works, I always discovered new problems that made me want to quit and go on without a step seqeuncer, but I think that now I have found all the "bugs" I need to get rid of to make this thing work with Traktor. And the idea of using my QuNeo, which would else be rather unused, in my actual setup is very tempting.
But, to be honest, I'm not that much into programming (I only know about pd for one week), and I think I could not program my own sequencer from scratch, at least in an acceptable amount of time and work. Plus, the Rhythmboy already has already 90% of the work I need done, and I'm a lazy person, in the techy meaning of lazy, which means not to do any work that is already done. For example, the story of this guy made me smile.
So yes, I'd love to fix the Rhythmboy, and put some work and learning into it, but I don't think I'd build a new step sequencer from scratch. Yet, I know that your help here already gave me a lot of ideas to work with, and I'm not one of those guys who expect someone else to solve the whole problem for me. I love to find my own solutions if someone points me into the right directions, which you already did, and my main goal is not a perfect program, but something that at least works as it should.
Now for the technicals: Yes, the Rhythmboy isn't polyphonic, but neither are the remix decks in Traktor. The remix decks in Traktor are multiple cells in multiple slots, that can be triggered by a MIDI command, and can be a loop or a one shot. So in other words, it's a very simple sampler.
Hi David, I am also David.
m0oonlib doesn't come with Pd-vanilla, but I am willing to get Pd-extended working (I'm actually prototyping for a patch that will run on a raspberry pi.) I definitely want to share these patches when I'm done, so I am using relative paths because I want it to run on different environments, with different file structures, with everything relative to the main patch.
declare /synths wouldn't that be an absolute location (at the root of my filesystem?)
open messages require 2 params, the second of which is the path. If you leave it off you will get this error:
Bad arguments for message 'open' to object 'pd'
I have tried it several ways, and all do not work:
(I get the
Bad Argument error)
With all of these I get
Device not configured:
These work, but are not ideal:
I'd prefer not hardcoding an absolute path.
moonlib/absolutepath doesn't seem to work with a directory name, only a file. That means this works:
But not this (the format I actually need for path):
This works, but really I'd just prefer a solution that works in Pd-vanilla:
use of threads for i²c I/O external : looking for a good strategy
I'm developing an audio device based on a cubieboard2(armf). I use potentiometers read by an adc that communicates through i²c protocol with my cubie. An i²c lcd display shows the desired parameters values.
I wrote externals in order to get data from the potentiometers (and other switches, and a rotary encoder), or send data to the display. Everything was working, but the i²c I/O functions calls were leading to clicks 'n pops in the audio, which was unacceptable. I use a rt patched debian with selected rt priorities for irqs and audio as I always did with success, and I am looking for a smart way to make my pd patches communicate with my physical interface, in a transparent way at audio level.
Then a opened this topic : http://forum.pdpatchrepo.info/topic/9489/external-i2c-data-reader-leads-to-clicks-standalone-version-works-better , and @Eeight proposed to implement threads, kindly giving a template in order to show me the way.
And now I'd need some advice. I'm not a real C programmer, just learning the empirical way, and I'm reaching my limits... I made a threaded version of the external that reads the potentiometers every x milliseconds, and it works perfectly, no audio pollution anymore. But when I made a threaded version of the external that handles the i²c display (thus receiving incoming messages such as "position x y", or "write message"), it lead to timing problems.
Some of the messages get uninterpreted because my writing function is threaded, and takes the form of an infinite while(1) loop containing a "usleep(10000)" instruction at the end of it in order to limit cpu load. The problem is that this leads to the "loss" of most of the incoming messages...
When reading potentiometers values, it's ok to get them merely one every 10ms, but when you have to send messages that can be interpreted merely one every 1oms, you have to send them to the external with delays, which works (That's my present situation), but is tiedious and inelegant.
Would someone have an idea of how this problem could be addressed in a more elegant manner ?
Here is how I implemented it :
- I create a thread for an infinite while (1) loop containing a call to a writing function whenever a flag equals 1, followed by a usleep(10000) instruction.
This "thread" is running from the beginning and awaits for a nonzero value of the flag to enter in action. It reads the string to be displayed from the object's data structure, but only when the "clocking" allows it together with the flag
- a "write" method can receive a t_symbol : the string to display. When a "write blahblah" message is received by the object, the string "blahblah" is stored in the object's data structure, as the flag which is set to 1.
- Then the next time the threaded loop evaluates the flag, it displays "blahblah", resets the flag to 0 and sleeps for 10ms.
But when you use incoming messages using 10 lines messages (allowing for cursor positioning and writing orders), they of course flow through the code in far less than 10ms, hence my problems... In other words the string to be displayed can be changed several times in the object's data structure without being actually displayed because of the relatively slow "clocking".
Please forget the incredible length of this message, together to the fact that I don't post the source yet because of a basic shame of my inelegant coding style. Maybe will I finally clean it and post it later.