Again C74 shits on your users, as he makes enough with Pluggo.
Arbitrary changes and are not consulted frequently, but a change of license which means C74 owns everything that is created in Gen development tool, it really is a gesture of usury only expect from a corporation like Microsoft.
Many users have been developing in Gen since leaving, and read attentively the license before investing money, time and other resources to learn and develop.

/****************************************
Copyright (c) 2012 Cycling ’74

Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies
or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*****************************************************/

/**********************************
Cycling ’74 License for Max-Generated Code for Export
Copyright (c) 2016 Cycling ’74
The code that Max generates automatically and that end users are capable of exporting and using, and any
associated documentation files (the "Software") is a work of authorship for which Cycling ’74 is the author
and owner for copyright purposes. A license is hereby granted, free of charge, to any person obtaining a
copy of the Software ("Licensee") to use, copy, modify, merge, publish, and distribute copies of the Software,
and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The Software is licensed to Licensee only for non-commercial use. Users who wish to make commercial use of the
Software must contact the copyright owner to determine if a license for commercial use is available, and the
terms and conditions for same, which may include fees or royalties. For commercial use, please send inquiries
to licensing (at) cycling74.com. The determination of whether a use is commercial use or non-commercial use is based
upon the use, not the user. The Software may be used by individuals, institutions, governments, corporations, or
other business whether for-profit or non-profit so long as the use itself is not a commercialization of the
materials or a use that generates or is intended to generate income, revenue, sales or profit.
The above copyright notice and this license shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
*****************************************************/

Anyway
My return to Pd...

Hi! I am running Pd-0.47-1-64bit on Mac OS 10.11.6 and libpd 0.9.2. I am trying to work with the samples/cpp/pdtest. Here's the github repo. I currently have an app that takes video and spits out a 2D array of color values for regions of interest to file. I have a pd patch that then loads those into a table and plays the corresponding pitch. I need the two (patch, c++ app) to coordinate the IPC.

I compiled the cpp code in the samples directory however, when running pdtest executable there is no patch opened. Is this by design? I was not able to find a pd-vanilla to build from source so took the most recent (pd-0.47-1-64bit.mac.tar.gz). Does libpd need to have the pd built after libpd? If so, can anyone please point me to a src file?

Here is a truncated output from running the compiled pdtest. Could someone tell me if this is what is expected?

Thank you for your help.

BEGIN Patch Test
Patch: "pd/test.pd" $0: 1003 valid: 1
Patch: "pd/test.pd" $0: 0 valid: 0
Patch: "pd/test.pd" $0: 1005 valid: 1
PD: PATCH OPENED: 1003
print: 0
PD: PATCH OPENED: 1005
print: 0
FINISH Patch Test

BEGIN Message Test
FINISH Message Test

BEGIN MIDI Test
FINISH MIDI Test

BEGIN Array Test
array1 len: 10
array1 0.0857145 0.328572 0.500001 0.57143 0.514287 0.47143 0.357144 0.285715 0.057143 0
array1 0 1 2 3 4 5 6 7 8 9
array1 10 10 10 10 10 10 10 10 10 10
FINISH Array Test

BEGIN PD Test
FINISH PD Test

Processing PD
PD: bang
PD: 100
PD: symbol test string
PD: bang
PD: 100
PD: symbol test string
PD: 1.23 a symbol
PD dollar zero: 1.23 a symbol
PD: 1.23 sent from a List object
PD: msg 1.23 sent from a List object
PD: 1.23 sent from a streamed list
PD MIDI: notein 2 60 64
PD MIDI: ctlin 2 0 64
PD MIDI: pgm 2 101
PD MIDI: midiin 1 239
PD: symbol test
PD: START MSG TEST
CPP: bang toCPP
CPP: float toCPP: 100
CPP: symbol toCPP: kaaa
CPP: list toCPP: 100 2.3 test 1 2 3 ffsfff
CPP: message toCPP: kaa 1 2.3 test ffs
PD: MSG TEST FINISH
PD: START MIDI TEST
PD: MIDI TEST FINISHED
PD: START ARRAY TEST
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD: FINISH ARRAY TEST
PD: test_abs: Hello World!
CPP MIDI: note on: 0 0 127
CPP MIDI: note on: 0 0 127
CPP MIDI: note on: 0 60 64
CPP MIDI: control change: 0 64 100
CPP MIDI: program change: 0 99
CPP MIDI: pitch bend: 0 2000
CPP MIDI: aftertouch: 0 100
CPP MIDI: poly aftertouch: 0 64 100
CPP MIDI: midi byte: 0 239
CPP: float env: 75.5457
CPP: float env: 87.9506
CPP: float env: 93.5842
...

CPP: float env: 88.5503
CPP: float env: 87.7612
print: 1
CPP MIDI: note on: 0 0 0
CPP MIDI: note on: 0 1 127
CPP: float env: 86.8932
...

CPP: float env: 41.2584
CPP: float env: 0
print: 2
CPP MIDI: note on: 0 1 0
CPP MIDI: note on: 0 2 127
...

print: 20
CPP MIDI: note on: 0 19 0
CPP MIDI: note on: 0 20 127

My friends, while this was a worm-hole that I Am glad I went down, I must let it go for my own peace of mind.

I am posting below the shell script I used to convert the faust files, but it is just too far away from what i Really want to do to continue.

Peace, good cheer to you, and may I get back on to making music again.

-svanya

#! /bin/bash
for dsp in `find '/root/00-MYSTUFF/zz_archive/01_tabled/compilefaust/pd-faust-0.4/examples' -name "*.dsp"`
do

FILE="$dsp"
extension="${dsp##*.}"
FILEBASE=$(basename "$FILE" .$extension)
base=`dirname "$dsp"`


echo "$dsp"
echo "$FILEBASE"
echo "$base"

# compile the Faust source and generate the xml file
faust -a puredata.cpp -xml "$dsp" -o "$FILEBASE".cpp
# compile the C++ module to a Pd plugin
g++ -shared -Dmydsp="$FILEBASE" "$FILEBASE".cpp -o "./pdfaust_built/$FILEBASE"~.pd_linux
# generate the Pd patch from the xml file
faust2pd "$dsp".xml --output-file "./pdfaust_built/$FILEBASE~-help.pd"
rm "$FILEBASE".cpp

done

To begin, I apologize in advance for this Not being a complete abstraction, so please forgive me for that.

As apology, I offer my humility: 10 hours-straight work later, I know some of what i thought of is beyond my knowledge limit and capacity to continue working on.

That all being said,...

My idea (which I thought would be Very simple, yet learned that PD, no matter how sweet She is, does not behave like the linux shell) was simple:

Make a rack of a set of vradios (i chose 8 due to the cpu limit on my laptop, but more could easily be added) which each denote a set of effects;

Send the results to a shell control along with the "slot" in the stack;

Have it copy that effect into an eff(ects)/tmp folder (mapping over the dummy files that were there),

so when the adc~ > eff1 > eff2, etc., chain runs they would be loaded as copies of the desired effects abstractions.

My intention was to empower the usage of multiple instances of the same effects abstractions as well as cut the wiring required in many/my pedal rack/s I have seen to almost nil.

That Was accomplished.

And I DO like the "idea".

On the other hand, I learned, to my chagrin, 2 VERY important lessons:

1. pd loads all subpatches on startup
   and
2. there is no (this is were I bow to higher minds than myself) way to "refresh" the patch, shy of closing and reopening it (because while you can do this sort of thing in linux, you can not in pd "underwrite" a subpatch and presume it will know the change has been made).

I Did pursue trying to load via "cat" the effect file-contents into a pd (sub)patch object, but could not figure out how to make that work, even with subtracting the file accouterments, i.e.#X, #N.

In closing I will say that the goal, though only partially achieved, IS one worth pursuing if it is a domain you are more knowledgeable about than myself.

I have attached a zip of my work.

It includes:

a shell script to start extended (it must be started this way, if the shell object is to know where the resource folder is located;

a folder, "res", which includes: /effs (where you put your effects abstractions), /effs_tmp (with 8 dummy files, where your effs get copied to), and /helper (where Mother is located)

and

a Mother_effsmap.txt file, where you list your effects, by filename (including the ".pd" extension", which it cross-references the vradio index to the line number on the file to know which file to copy.

Also,
I have found that it does copy correctly, but then you are left with the stack of controls to contend with. But I have yet to figure that out and think it better to go ahead and share it.

-peace, thanks for listening, and I hope it gives you some new ideas to work with.

svanya

Mother.zip

Hi guys,

I'm developing a webcam sampler with the help of Bryan Chung's Multimedia Programming in Pd book. I've created four points on the screen that uses changing colour hues to trigger samples, I've also used [switch~]ing to the four [readsf~] objects for each sample to minimise CPU usage on audio. All seems to work fine. However, when the GEM window is activated for the webcam, my CPU usage jumps up by about 30 % and creates audio errors! Is there a way to reduce CPU usage with GEM windows/webcams etc? Would FPS and other methods make a difference?

Patch is here webcam.pd

cheers

Casper

@Pierre-Guillot
"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'

@Pierre-Guillot

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'```

Sorry, guys, but I think you're missing my point on what I'm trying to accomplish.

There's no single parent canvas. There can be multiple parents. And my GOP abstraction should work regardless of how many parents it has and which of the parent windows is visible.

Let's consider an example. We have a patch called patch.pd (not created by me, but by the user of my abstraction). Inside patch.pd there's a GOP subpatch: [pd $0-level1] (position and size of GOP area are arbitrary). Inside it there's my GOP abstraction [myhovertest].

Now, if I use [iemguts/canvasposition 2] in myhovertest.pd, it's going to return the position of $0-level1 relative to the top right corner of the main patch. So if we subtract this position from mouse position that we got from receivecanvas, we can get the position of the mouse relative to $0-level1's GOP area. The issue is, there seems to be no way of determining the position of GOP area programmatically, so we have no way of knowing where the mouse is relative to our abstraction [myhovertest]. [iemguts/canvasposition 1] returns position of [myhovertest] relative to $0-level1's window, but what we really need to know is the position of [myhovertest] relative to $0-level1's GOP area.

I hope I explained this well...

I have a DSP chain. It begins with pitch tracking with sigmund~ and then a series of abstractions follow that have a switch~ in each, controlled by polygate~ output (i.e. once I switch off an abstraction in the chain, polygate~ sends a zero to switch~ in that abstraction. Vice versa. It works well.

The problem. When I load the patch and switch~ on the 6 instances of sigmund~ (which is generally CPU heavy in itself, but I have never had a problem with it until now) the CPU rises to around 90%, whereas before redesign of the chain (I've replaced a few abstractions which may be a little more CPU intensive, but not much), the CPU was barely over 50%.

The weird thing. When I switch ON the rest of the DSP chain, the CPU drops to 70% (which is where I would expect it to be).

My question(s). What the hell is going on? Why is sigmund~ wetting the bed before the rest of the chain is on? Is my computer having a crisis?

Cheers,

Ricky

p.s. Abstractions are not in parent patch.

using env~ to compute input for vu meters seems cpu intensive. i have an app using 11 stereo audio paths (7 rows mixed to one of 4 audio outputs), and i have created a pair of vu meters for each. each vu input looks like this:

[env~ 8192 4096]
|
[- 100]
|
[vu]

i have set the arguments for env~ to a larger sampling window, which helps somewhat, but this is still chewing up a lot of cpu.

i am on a windows 7 machine, and with the env~ objects in place, cpu use (according to windows task manager) ranges from 40-60%. if i simply remove the env~ objects and change nothing else in my program, cpu usage is ~10-15%.

any suggestions for a less cpu intensive way to display some sense of audio level? it does not have to be really precise, but i would like for it to be fairly responsive.

thank you!