2. Search
49 result(s) matching "logic-pro-intel-mac", (0.05 seconds)

How to make the outlet port "hot area" a bit larger?

@ddw_music said:

Does anyone know offhand where to hack the hot zone size, so that maybe one does not have to have superhuman precision?

searching sources for

mouse

I found in https://github.com/pure-data/pure-data/blob/20334410c20948f14f5c1d8ae5ed992717b83291/tcl/pd-gui.tcl

            # mouse cursors for all the different modes

[...]

            set ::cursor_editmode_connect "circle"

.
Then searching for

cursor_editmode_connect

I found probably relevant
https://github.com/pure-data/pure-data/blob/c4ae1bd8df436de15c0a80f303ae33b5f3569088/src/g_editor.c

  /* look for an outlet */
            else if (hitobj && (noutlet = obj_noutlets(hitobj)) &&
                ypos >= y2 - (OHEIGHT*x->gl_zoom) + x->gl_zoom)
            {
                int width = x2 - x1;
                int iow = IOWIDTH * x->gl_zoom;
                int nout1 = (noutlet > 1 ? noutlet - 1 : 1);
                int closest = ((xpos-x1) * (nout1) + width/2)/width;
                int hotspot = x1 +
                    (width - iow) * closest / (nout1);
                if (closest < noutlet &&
                    xpos >= (hotspot - x->gl_zoom) &&
                    xpos <= hotspot + (iow + x->gl_zoom))
                {
                    if (doit)
                    {

[...]

/* not in an outlet; select and move */

...Searching the sources for IOWITH
or better OHEIGHT
has this result among others:

https://github.com/pure-data/pure-data/blob/5462d1eae0ad9f139997d56d459c212e797d96be/src/g_canvas.h

* --------------------- geometry ---------------------------- */
#define IOWIDTH 7       /* width of an inlet/outlet in pixels */
#define IHEIGHT 3       /* height of an inlet in pixels */
#define OHEIGHT 3       /* height of an outlet in pixels */
#define IOMIDDLE ((IOWIDTH-1)/2)
#define GLIST_DEFGRAPHWIDTH 200
#define GLIST_DEFGRAPHHEIGHT 140

#define GLIST_DEFCANVASXLOC 0
#ifdef __APPLE__
#define GLIST_DEFCANVASYLOC 22
#else
#define GLIST_DEFCANVASYLOC 50
#endif

.

(Not sure how the apparently different size of inlets and outlets hot area is coded? Inlets appear to be 'magnetic'. )

Wish there was a shortcut to open objects-help.

Could belong here:
https://github.com/pure-data/pure-data/blob/90ad8005199605095e49dbbf1daf4f032211b7f4/tcl/pd_bindings.tcl

posted in technical issues

Feature request for [receive] object

another option is [iem_receive] from iemlib.

This feature seems trivial on surface, but it is really not. If implemented naively, it can crash Pd under certain circumstances. For a technical discussion, see https://github.com/pure-data/pure-data/pull/604. Making it safe would require some changes to Pd internals, see https://github.com/pure-data/pure-data/pull/849.

posted in technical issues

Can't install purr-data on Manjaro

Hey, I'm trying to get purr-data to work on my fresh Manjaro XFCE install, but it does not work. Any help is greatly appreciated!

$ yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00) 
    Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00) 
    Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00) 
    LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00) 
    Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00) 
    A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00) 
    Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17) 
    Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
    1) gconf 2) gconf-gtk2 

Enter a number (default=1): ==> 
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2]  gconf-3.2.6+11+g07808097-10  purr-data-git-2.12.0.r4366.6d94e10b-1

  2 gconf                                    (Build Files Exist)
  1 purr-data-git                           
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/1): /home/olav/.cache/yay/gconf
:: (1/2) Downloaded PKGBUILD: gconf
:: (2/2) Downloaded PKGBUILD: purr-data-git
  2 gconf                                    (Build Files Exist)
  1 purr-data-git                            (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 
:: (1/2) Parsing SRCINFO: gconf
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
  -> Cloning gconf git repo...
Cloning into bare repository '/home/olav/.cache/yay/gconf/gconf'...
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
  -> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
remote: Enumerating objects: 21531, done.
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 21531 (delta 0), reused 0 (delta 0), pack-reused 21531
Receiving objects: 100% (21531/21531), 10.88 MiB | 9.46 MiB/s, done.
Resolving deltas: 100% (17681/17681), done.1 KiB | 704.00 KiB/s
  -> Found 01_xml-gettext-domain.patch388.01 KiB | 704.00 KiB/s
  -> Found gconf-reload.patch
  -> Found gconf-merge-schema
  -> Found gconfpkg
  -> Found gconf-install.hook
  -> Found gconf-remove.hook
==> Validating source files with sha256sums...
    gconf ... Skipped
    01_xml-gettext-domain.patch ... Passed
    gconf-reload.patch ... Passed
    gconf-merge-schema ... Passed
    gconfpkg ... Passed
    gconf-install.hook ... Passed
    gconf-remove.hook ... Passed
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 5.71 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
  -> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 86.7M  100 86.7M    0     0  3966k      0  0:00:22  0:00:22 --:--:-- 8404k
==> Validating source files with md5sums...
    purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
    nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:24:19 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating gconf git repo...
Fetching origin
  -> Found 01_xml-gettext-domain.patch
  -> Found gconf-reload.patch
  -> Found gconf-merge-schema
  -> Found gconfpkg
  -> Found gconf-install.hook
  -> Found gconf-remove.hook
==> Validating source files with sha256sums...
    gconf ... Skipped
    01_xml-gettext-domain.patch ... Passed
    gconf-reload.patch ... Passed
    gconf-merge-schema ... Passed
    gconfpkg ... Passed
    gconf-install.hook ... Passed
    gconf-remove.hook ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Creating working copy of gconf git repo...
Cloning into 'gconf'...
done.
Switched to a new branch 'makepkg'
==> Starting prepare()...
/home/olav/.cache/yay/gconf/PKGBUILD: line 30: patch: command not found
==> ERROR: A failure occurred in prepare().
    Aborting...
 -> error making: gconf

And

yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00) 
    Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00) 
    Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00) 
    LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00) 
    Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00) 
    A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00) 
    Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17) 
    Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
    1) gconf 2) gconf-gtk2 

Enter a number (default=1): ==> 
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2]  gconf-3.2.6+11+g07808097-10  purr-data-git-2.12.0.r4366.6d94e10b-1

  2 gconf                                    (Build Files Exist)
  1 purr-data-git                           
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/1): /home/olav/.cache/yay/gconf
:: (1/2) Downloaded PKGBUILD: gconf
:: (2/2) Downloaded PKGBUILD: purr-data-git
  2 gconf                                    (Build Files Exist)
  1 purr-data-git                            (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 
:: (1/2) Parsing SRCINFO: gconf
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
  -> Cloning gconf git repo...
Cloning into bare repository '/home/olav/.cache/yay/gconf/gconf'...
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
  -> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
remote: Enumerating objects: 21531, done.
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 21531 (delta 0), reused 0 (delta 0), pack-reused 21531
Receiving objects: 100% (21531/21531), 10.88 MiB | 9.46 MiB/s, done.
Resolving deltas: 100% (17681/17681), done.1 KiB | 704.00 KiB/s
  -> Found 01_xml-gettext-domain.patch388.01 KiB | 704.00 KiB/s
  -> Found gconf-reload.patch
  -> Found gconf-merge-schema
  -> Found gconfpkg
  -> Found gconf-install.hook
  -> Found gconf-remove.hook
==> Validating source files with sha256sums...
    gconf ... Skipped
    01_xml-gettext-domain.patch ... Passed
    gconf-reload.patch ... Passed
    gconf-merge-schema ... Passed
    gconfpkg ... Passed
    gconf-install.hook ... Passed
    gconf-remove.hook ... Passed
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 5.71 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
  -> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 86.7M  100 86.7M    0     0  3966k      0  0:00:22  0:00:22 --:--:-- 8404k
==> Validating source files with md5sums...
    purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
    nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:24:19 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating gconf git repo...
Fetching origin
  -> Found 01_xml-gettext-domain.patch
  -> Found gconf-reload.patch
  -> Found gconf-merge-schema
  -> Found gconfpkg
  -> Found gconf-install.hook
  -> Found gconf-remove.hook
==> Validating source files with sha256sums...
    gconf ... Skipped
    01_xml-gettext-domain.patch ... Passed
    gconf-reload.patch ... Passed
    gconf-merge-schema ... Passed
    gconfpkg ... Passed
    gconf-install.hook ... Passed
    gconf-remove.hook ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Creating working copy of gconf git repo...
Cloning into 'gconf'...
done.
Switched to a new branch 'makepkg'
==> Starting prepare()...
/home/olav/.cache/yay/gconf/PKGBUILD: line 30: patch: command not found
==> ERROR: A failure occurred in prepare().
    Aborting...
 -> error making: gconf
[olav@AMD-Computer ~]$ yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00) 
    Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00) 
    Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00) 
    LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00) 
    Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00) 
    A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00) 
    Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17) 
    Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
    1) gconf 2) gconf-gtk2 

Enter a number (default=1): ==> 2
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2]  gconf-gtk2-3.2.6-5  purr-data-git-2.12.0.r4366.6d94e10b-1

  2 gconf-gtk2                               (Build Files Exist)
  1 purr-data-git                            (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/2): /home/olav/.cache/yay/gconf-gtk2
:: Deleting (2/2): /home/olav/.cache/yay/purr-data-git
:: (1/2) Downloaded PKGBUILD: purr-data-git
:: (2/2) Downloaded PKGBUILD: gconf-gtk2
  2 gconf-gtk2                               (Build Files Exist)
  1 purr-data-git                            (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 
:: (1/2) Parsing SRCINFO: gconf-gtk2
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:40:58 PM CET)
==> Retrieving sources...
==> Making package: gconf-gtk2 3.2.6-5 (Wed 09 Feb 2022 10:40:58 PM CET)
==> Retrieving sources...
  -> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
  -> Downloading GConf-3.2.6.tar.xz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 1523k  100 1523k    0     0  1610k      0 --:--:-- --:--:-- --:--:-- 1610k
  -> Found gconf-merge-schema
  -> Found gconfpkg
  -> Found gconf-reload.patch
  -> Found gconf-install.hook
  -> Found gconf-remove.hook
  -> Found 01_xml-gettext-domain.patch
  -> Found dbus-dontspew.patch
  -> Found gsettings-data-convert-fix-invalid-schema-path.patch
==> Validating source files with sha256sums...
    GConf-3.2.6.tar.xz ... Passed
    gconf-merge-schema ... Passed
    gconfpkg ... Passed
    gconf-reload.patch ... Passed
    gconf-install.hook ... Passed
    gconf-remove.hook ... Passed
    01_xml-gettext-domain.patch ... Passed
    dbus-dontspew.patch ... Passed
    gsettings-data-convert-fix-invalid-schema-path.patch ... Passed
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 9.76 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
  -> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 86.7M  100 86.7M    0     0  11.7M      0  0:00:07  0:00:07 --:--:-- 14.4M
==> Validating source files with md5sums...
    purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
    nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf-gtk2 3.2.6-5 (Wed 09 Feb 2022 10:41:26 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found GConf-3.2.6.tar.xz
  -> Found gconf-merge-schema
  -> Found gconfpkg
  -> Found gconf-reload.patch
  -> Found gconf-install.hook
  -> Found gconf-remove.hook
  -> Found 01_xml-gettext-domain.patch
  -> Found dbus-dontspew.patch
  -> Found gsettings-data-convert-fix-invalid-schema-path.patch
==> Validating source files with sha256sums...
    GConf-3.2.6.tar.xz ... Passed
    gconf-merge-schema ... Passed
    gconfpkg ... Passed
    gconf-reload.patch ... Passed
    gconf-install.hook ... Passed
    gconf-remove.hook ... Passed
    01_xml-gettext-domain.patch ... Passed
    dbus-dontspew.patch ... Passed
    gsettings-data-convert-fix-invalid-schema-path.patch ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Extracting GConf-3.2.6.tar.xz with bsdtar
==> Starting prepare()...
/home/olav/.cache/yay/gconf-gtk2/PKGBUILD: line 39: patch: command not found
==> ERROR: A failure occurred in prepare().
    Aborting...
 -> error making: gconf-gtk2

posted in technical issues

What should I do (again!) about graphics?

OK. So another semester has passed, and I'm still stuck with the same dilemma about graphics in Pd.

Gem:

  • Pro: Features (image analysis, tons of pix_es).
  • Pro: Long history.
  • Pro: Design fits well into the Pd paradigm.
  • Con: Some students on Mac couldn't use it.
  • Con: Some students in Windows couldn't use it.
  • Con: How is it 2021 and it doesn't automatically enable antialiasing? (Part of me wants to apologize for being punchy about this, but... it is actually 2021. Anti-aliasing is standard. Because GEM has problems with it, it looks really REALLY out of date. Like, if Pd used eight-bit integer samples only. That kind of out of date. And no, [polygon_smooth] does exactly nothing on my system. I tried. No effect at all.)
  • Con: Some more complex use cases were really difficult for me to figure out (e.g., unclear when [pix_buffer] is or isn't needed).

Ofelia:

  • Pro: Examples look very slick and performant.
  • Pro: Anti-aliasing (generally beautiful rendering).
  • Pro: 60Hz's abstractions make it more approachable, for basic use cases.
  • Con: Outside of the basic use cases, Lua will be very hard for the students in my class to approach.
  • Con: No image analysis features. (Open Frameworks has ofxOpenCV as an add-on, but it isn't easy to use add-ons with Ofelia, especially if I have to provide binaries of my own Ofelia fork to students in both Mac and Windows.) So... "You know how in Gem or jitter, you can read the webcam and do stuff with the data? Yeah. You can't do that with Ofelia." (At which point, clever students would ask why I'm using it at all.) IMO this is a massive, huge, gaping hole in Ofelia's feature set.
  • Con: 60Hz's abstractions have so far undergone limited testing.
  • Con: I would have to redevelop/port various shaders, and still not approach the number of pixes in Gem.

Max/MSP/jitter:

  • Pro: Well, it just works.
  • Con: Make me boot into Windows several times a week to prepare course material. Grrrrrr.
  • Con: Not FLOSS.

Rewrite the entire course using SC and Processing:

  • Pro: Everything works.
  • Con: Students here won't touch code.

Quit my job:

  • Pro: Relax and make music.
  • Con: Run out of money in a few years.

I don't know what to do, and I have about a week to make a decision. If I go with Ofelia, I will have to put off other projects because it's going to take a bunch of work to get a handful of shaders up and running. I don't really want to do that. But, last fall semester, there were a few student machines that just couldn't run Gem. One of them could hack [gemwin] but that kind of thing shakes confidence.

I would really like Ofelia to add ofxOpenCV. I would just about not hesitate to use it then.

hjh

posted in pixel#

How to save sounds generated in Pure Data as virtual instruments or otherwise capitalize on them in Cakewalk?

I am learning the basic concepts of music production by exploring the capabilities of Cakewalk by Bandlab as well as Pure Data. My question is about how to capitalize on the sounds one generates in Pure Data.

I assume that although it is possible to write music entirely in Pure Data, most producers in some fashion export sounds from Pure Data into a DAW for further arrangement. The most sensible way to do this that I can see would be to make virtual instruments out of one's Pure Data creations.

Suppose I create a sound I like in Pure Data, either using a synthesizer written in Pure Data, or by some unstructured process of playing with sinesums/drawing freehand sound waves in tables/etc. How can I make a custom virtual instrument in Cakewalk from such a sound? I found this (

) tutorial for creating virtual instruments, but it doesn't discuss Cakewalk, and the tutorial involves audio recording from a physical instrument. Would sound generated in Pure Data have to be recorded in order to be ported to a DAW, or could it be transferred through an entirely digital process, since the sound in Pure Data originates digitally?

If this is not the right way to go about utilizing Pure Data sounds in a DAW, then what is?

posted in output~

Purr Data GSoC Projects, 2.15.1

Hi all,

Purr Data 2.15.1 has been released.

We had some build issues and Albert graciously stepped up to help merge the relevant patches and posted the release on github quite quickly:

https://github.com/agraef/purr-data/releases

If you're on Gnu/Linux, do use the OBS repos that he set up. He's posted a very clear guide, and if you use it you'll get Purr updated automatically any time you update the system.

As always, report issues here:

https://git.purrdata.net/jwilkes/purr-data/-/issues

With that out of the way, I'd like to highlight the work our students did for Google Summer of Code Projects that wrapped up over a month ago.

Patch Private Abstractions

This was a feature created by Guillem Bartrina. (Actually, one of several features he added as part of his GSoC project this summer. I'll try to post about his other additions later.) It allows the user to create and use abstractions which get saved in the parent patch. Abstraction names are local to the patch which contains them, which makes for a quite workable and flexible namespacing system that's easy to use and understand.

ab.webm

This is a very tricky feature to design and get right, and Guillem did an excellent job considering various corner cases and optimal UX. Notice in the video that he added a few features which are useful generally for abstractions, too:

  • a notification when the user has an unsaved abstraction somewhere in the running instance
  • another notification when the user has two or more unsaved abstractions in the running instance. This is quite a handy feature for normal abstractions, too, as it can save you from the headache of overwriting important changes when you're working after midnight on your last cup of coffee! :)

There are also some helper classes that give some options to ensure that the user doesn't lose data.

Purr Data Webapp

This was another ambitious project with frontend work by Hugo Neves de Carvalho and backend, API, and merging work by Zack Lee.

This project runs the core of Purr Data and a surprisingly large number of all the externals it ships in a webpage. The front end can load, save, close, and "vis" multiple patches and run them from the same backend engine.

purrweb.webm

Thanks to the way Zack leveraged the emscripten file system, you can even save abstractions and call them from a new patch!

purrweb2.webm

The patch private abstractions have already been merged into Purr Data, and we're currently working on upstreaming the webapp changes into Purr Data as well.

posted in news

[SOLVED]video still remains after disconnecting [ofelia d] script

I've modified some abstractions created by @60hz for prototyping fast with ofelia (BTW, thanks a million for your abstractions they're great! And of course a million thanks to @cuinjune for creating Ofelia!). Things seem to work OK, but there's this happening. I have the following patch (I've changed the names from [gl.draw] to [ofelia.draw] for this and other abstractions)

[ofelia.draw]
|
[ofelia.cube]

and I see a white cube in the Ofelia window. Then I make the following connections:

[ofelia.draw]
|
[ofelia.movie]
|
[ofelia.cube]

and I get a video playing in the same cube. Till now everything is fine. But if I go back to the first patch, I don't get a white cube anymore but a still from the video file from [ofelia.movie]. Here are the scripts of the abstractions (almost identical to @60hz abstractions):
[ofelia.draw] (I'm returning ofColor because I want to have all abstractions output pointers and not bangs, maybe there's a better solution for this):

ofelia d draw$0;
local c = ofCanvas(this);
local args = c:getArgs();
local depth = true;
local screenwidth;
local screenheigh;
local widthHeigh;
;
function M.new();
  if args[2] == nil then depth = true;
  else;
  M.depth(args[2]);
  end;
  if ofWindow.exists then;
  screenwidth = ofGetWidth();
  screenheight = ofGetHeight();
  end;
end;
;
function M.screensize(list);
  screenwidth, screenheight = list[1], list[2];
end;
;
function M.depth(string);
  if string == "3d" then;
  depth = true;
  else;
  depth = false;
  end;
end;
function M.bang();
  ofSetDepthTest(depth);
  ofTranslate(screenwidth*0.5, screenheight*0.5);
  return ofColor(255, 255, 255);
end;

[ofelia.movie]:

ofelia d -c17 videoplayer-$0;
local canvas = ofCanvas(this);
local args = canvas:getArgs();
local videoplayer = ofVideoPlayer();
local filename, start, loop = args[1], args[2], args[3];
local loaded = 0;
;
function M.new();
  ofWindow.addListener("setup", this);
  if args[1] == nil then print("No file found");
  else M.open(filename);
  end;
  if args[2] == 1 then M.play();
  end;
  if args[3] == nil then loop = 0;
  end;
end;
;
function M.free();
  ofWindow.removeListener("setup", this);
end;
;
function M.setup();
  M.open(filename);
end;
;
function M.open(string);
  if ofWindow.exists then;
    videoplayer:close();
    videoplayer:load(string);
    if (videoplayer:isLoaded()) then;
    print("loaded " .. string);
    videoplayer:update();
    end;
  end;
end;
function M.url(string);
  if ofWindow.exists then;
    videoplayer:close();
    videoplayer:load(string);
    if (videoplayer:isLoaded()) then;
      print("loaded " .. string);
      videoplayer:update();
    end;
  end;
end;
function M.play() videoplayer:play() end;
function M.stop() videoplayer:stop() end;
function M.pause() videoplayer:setPaused(true) end;
function M.speed(float) videoplayer:setSpeed(float) end;
function M.frame(float) videoplayer:setFrame(float) end;
function M.volume(float) videoplayer:setVolume(float) end;
function M.loop(float);
  if float == 0 then videoplayer:setLoopState(OF_LOOP_NONE);
  elseif float == 1 then videoplayer:setLoopState(OF_LOOP_NORMAL);
  elseif float == 2 then videoplayer:setLoopState(OF_LOOP_PALINDROME);
  end;
end;
function M.get()
  return ofTable (videoplayer, videoplayer:isLoaded(), videoplayer:isPlaying(), videoplayer:getCurrentFrame(), videoplayer:getTotalNumFrames(), videoplayer:getWidth(), videoplayer:getHeight());
end;
;
function M.pointer(p);
  videoplayer:update();
  videoplayer:bind();
  return videoplayer;
end;
function M.bang();
  videoplayer:update();
  videoplayer:bind();
  return videoplayer;
end;

Inside [ofelia.movie] there's this patch:

[ofelia d movie_script] <- this is the ofelia object that loads the script above
|
[t a a]
|    |
|    [outlet]
|
[ofelia d videoplayer_unbind;] <- this is one object
[function M.pointer(p);      ]
[p:unbind;                   ]
[end;                        ]

and this is [ofelia.cube]:

ofelia d $0-box;
local c = ofCanvas(this);
local args = c:getArgs();
local width, height, depth, resw, resh, resd, drawmode, strokeweight = args[1], args[2], args[3], args[4], args[5], args[6], args[7], args[8];
local position, orientation, scale = ofVec3f(0, 0, 0), ofVec3f(0, 0, 0), ofVec3f(1, 1, 1);
;
function M.new();
  ofWindow.addListener("setup", this);
  if args[1] == nil then width = 100 end;
  if args[2] == nil then height = 100 end;
  if args[3] == nil then depth = 100 end;
  if args[4] == nil then resw = 5 end;
  if args[5] == nil then resh = 5 end;
  if args[6] == nil then resd = 5 end;
  if args[7] == nil then drawmode = "fill" end;
  if args[8] == nil then strokeweight = 1 end;
  M.setup();
end;
;
function M.free();
  ofWindow.removeListener("setup", this)
end;
;
function M.setup();
  box$0 = ofBoxPrimitive();
end;
;
function M.resw(float) resw = float end;
function M.resh(float) resh = float end;
function M.resd(float) resd = float end;
function M.width(float) width = float end;
function M.height(float) height = float end;
function M.depth(float) depth = float end;
function M.draw(string) drawmode = string end;
function M.stroke(float) strokeweight = float end;
function M.position(list) position = ofVec3f(list[1], list[2], list[3]) end;
function M.orientation(list) orientation = ofVec3f(list[1], list[2], list[3]) end;
function M.scale(list) scale = ofVec3f(list[1], list[2], list[3]) end;
;
function M.pointer(p);
  ofSetLineWidth(strokeweight);
  box$0:setPosition (position:vec3());
  box$0:setOrientation (orientation:vec3());
  box$0:setScale (scale:vec3());
  box$0:set(width, height, depth, math.abs(resw), math.abs(resh), math.abs(resd));
  if drawmode == "fill" then box$0:drawFaces() end;
  if drawmode == "point" then box$0:drawVertices() end;
  if drawmode == "line" then box$0:drawWireframe() end;
  return p;
end;
function M.bang();
  ofSetLineWidth(strokeweight);
  box$0:setPosition (position:vec3());
  box$0:setOrientation (orientation:vec3());
  box$0:setScale (scale:vec3());
  box$0:set(width, height, depth, math.abs(resw), math.abs(resh), math.abs(resd));
  if drawmode == "fill" then box$0:drawFaces() end;
  if drawmode == "point" then box$0:drawVertices() end;
  if drawmode == "line" then box$0:drawWireframe() end;
  return anything;
end;

This is a bit too much information but I think it's necessary if anyone can help. There's probably stuff I'm ignorant of. @cuinjune any hints?

posted in pixel#

[text sequence] access wait times in 'auto' mode?

@whale-av Ah, right -- I didn't explain clearly. So maybe it's time to "begin at the beginning."

Where I'm coming from: In SuperCollider, it's easy to express the idea of an event now, with a duration of 100 ms (time until the next event), with the gate open for the first 40% of that time:

(midinote: 60, dur: 0.1, legato: 0.4)

... producing control messages (0.04 is indeed 40% of 0.1 sec):

[ 0.0, [ 9, default, 1000, 0, 1, out, 0, freq, 261.6255653006, amp, 0.1, pan, 0.0 ] ]
[ 0.04, [ 15, 1000, gate, 0 ] ]

That is, an event is conceived as a span of time, with the action occurring at the beginning of the time span.

By contrast:

seq-01-simple-print.png

reset: line 0
reset: bang
w: 100

What is the data point that should occur at the beginning of this 100 ms span?

OK, never mind, continuing...

bang: bang
d: 60
w: 200

Ohhhh... it's really 200 ms for midinote 60. But you didn't know that at the time the data came out of the left outlet. Normally we assume right to left, but at the moment of requesting the next data from the sequencer, it's actually left to right.

bang: bang
d: 62
w: 300
bang: bang
d: 64

And... (the really unfortunate flaw in this design) -- how long is 64's time span? You... don't know. It's undefined. (You can add a duration without a data value at the end -- and I'll do that for the rest of the examples -- but... I'm going to have to explain this to students in a couple of days... if there are any clever ones in the lot, they will ask "Why is this note's duration on the next line? Why do we need an extra line?")

Let's try packing them:

seq-02-pack.png

reset: line 0
reset: bang
bang: bang
notedur: 60 100
bang: bang
notedur: 62 200
bang: bang
notedur: 64 300
bang: bang
notedur: 64 400  (this is with "400;" at the end of the seq)
bang: bang

Now, that "looks" like what I said I wanted -- but it's misleading, because the actual amount of time between 60 100 and 62 200 is 200 ms. The notes will be too short.

seq-03-flip.png

reset: line 0
reset: bang
notedur: 64 100  -- "64" is leftover data
bang: bang
notedur: 60 200  -- OK, matches sound
bang: bang
notedur: 62 300  -- OK
bang: bang
notedur: 64 400  -- OK
bang: bang

So the last version is closer -- just needs a little logic to suppress the first output (which I did in the abstraction).

Then, to run it as a sequence, it just needs [t b f f] coming from the wait outlet, and one of the f's goes to [delay] --> [s go]. So the completed 40% patch (minus first-row suppression) looks like this:

seq-03-40pct.png

I guess part of my point is that it took me almost two hours to work this out yesterday... but sequencing is a basic function of any music environment... isn't there some way to make it simpler to handle the very common musical conception of a note with a (subsequent) duration? (Pd already has exactly that conception -- [makenote] -- so, why is the sequencer at odds with [makenote]?)

hjh

posted in technical issues

sending / receiving variables with emscripten ofelia?

Actually I found a way to use emscripten_run_script() with Ofelia.
These are the steps:

I added

#include "/home/jonathan/emsdk/fastcomp/emscripten/system/include/emscripten/emscripten.h"

(not sure if I need the full path)
and

static void pdEmscriptenRunScript(std::string str)
{
    emscripten_run_script(const_cast<char*>(str.c_str()));
}

to ofxOfeliaPdBindings.h

Run updatePdBindings.sh in scripts/common

Add

{"ofEmscriptenRunScript",{{{4},{}},0}},

to ofxOfeliaMaps.cpp

and

mapper.addFunctionToRename({"pdEmscriptenRunScript", "ofEmscriptenRunScript"});

to updateMaps.cpp

  1. Run updateMaps.sh from scripts/common

Thats it. Not sure if something is redundant, but it works.

  1. Call the function from an Ofelia Lua script like:
ofEmscriptenRunScript(string.format("console.log('hello world')"))

in Open Frameworks it is written:

emscripten_run_script("console.log('hello world')");

or

ofEmscriptenRunScript(string.format("console.log(%f)", ofGetElapsedTimef()))

in Open Frameworks it is written:

emscripten_run_script("console.log($0)", ofGetElapsedTimef());

A bit easier to implement than EM_ASM, EM_ASM_ and EM_ASM_INT, but I think I am at the right track (hints are still very welcome)...

posted in libpd / webpd

PD's scheduler, timing, control-rate, audio-rate, block-size, (sub)sample accuracy,

Hello, :sparkles:

this is going to be a long one.
After years of using PD, I am still confused about its' timing and schedueling.

I have collected many snippets from here and there about this topic,
-wich all together are really confusing to me.

*I think it is very important to understand how timing works in detail for low-level programming … *

(For example the number of heavy jittering sequencers in hard and software make me wonder what sequencers are made actually for ? lol )

This is a collection of my findings regarding this topic, a bit messy and with confused questions.

I hope we can shed some light on this.

:lips: :eyes: :ear:

The answers where:

„
[...] it's just that messages actually only process every 64 samples at the least. You can get a bang every sample with [metro 1 1 samp] but it should be noted that most pd message objects only interact with each other at 64-sample boundaries, there are some that use the elapsed logical time to get times in between though (like vsnapshot~)
also this seems like a very inefficient way to do per-sample processing..
https://github.com/sebshader/shadylib http://www.openprocessing.org/user/29118
seb-harmonik.ar posted about a year ago , last edited by seb-harmonik.ar about a year ago 
• 1 
 whale-av 
@lacuna An excellent simple explanation from @seb-harmonik.ar.
Chapter 2.5 onwards for more info....... http://puredata.info/docs/manuals/pd/x2.htm
David.
“

There is written: http://puredata.info/docs/manuals/pd/x2.htm

„2.5. scheduling 
Pd uses 64-bit floating point numbers to represent time, providing sample accuracy and essentially never overflowing. Time appears to the user in milliseconds. 
2.5.1. audio and messages 
Audio and message processing are interleaved in Pd. Audio processing is scheduled every 64 samples at Pd's sample rate; at 44100 Hz. this gives a period of 1.45 milliseconds. You may turn DSP computation on and off by sending the "pd" object the messages "dsp 1" and "dsp 0." 
In the intervals between, delays might time out or external conditions might arise (incoming MIDI, mouse clicks, or whatnot). These may cause a cascade of depth-first message passing; each such message cascade is completely run out before the next message or DSP tick is computed. Messages are never passed to objects during a DSP tick; the ticks are atomic and parameter changes sent to different objects in any given message cascade take effect simultaneously. 
In the middle of a message cascade you may schedule another one at a delay of zero. This delayed cascade happens after the present cascade has finished, but at the same logical time. 
2.5.2. computation load 
The Pd scheduler maintains a (user-specified) lead on its computations; that is, it tries to keep ahead of real time by a small amount in order to be able to absorb unpredictable, momentary increases in computation time. This is specified using the "audiobuffer" or "frags" command line flags (see getting Pd to run ). 
If Pd gets late with respect to real time, gaps (either occasional or frequent) will appear in both the input and output audio streams. On the other hand, disk strewaming objects will work correctly, so that you may use Pd as a batch program with soundfile input and/or output. The "-nogui" and "-send" startup flags are provided to aid in doing this. 
Pd's "realtime" computations compete for CPU time with its own GUI, which runs as a separate process. A flow control mechanism will be provided someday to prevent this from causing trouble, but it is in any case wise to avoid having too much drawing going on while Pd is trying to make sound. If a subwindow is closed, Pd suspends sending the GUI update messages for it; but not so for miniaturized windows as of version 0.32. You should really close them when you aren't using them. 
2.5.3. determinism 
All message cascades that are scheduled (via "delay" and its relatives) to happen before a given audio tick will happen as scheduled regardless of whether Pd as a whole is running on time; in other words, calculation is never reordered for any real-time considerations. This is done in order to make Pd's operation deterministic. 
If a message cascade is started by an external event, a time tag is given it. These time tags are guaranteed to be consistent with the times at which timeouts are scheduled and DSP ticks are computed; i.e., time never decreases. (However, either Pd or a hardware driver may lie about the physical time an input arrives; this depends on the operating system.) "Timer" objects which meaure time intervals measure them in terms of the logical time stamps of the message cascades, so that timing a "delay" object always gives exactly the theoretical value. (There is, however, a "realtime" object that measures real time, with nondeterministic results.) 
If two message cascades are scheduled for the same logical time, they are carried out in the order they were scheduled. 
“

[block~ smaller then 64] doesn't change the interval of message-control-domain-calculation?,
Only the size of the audio-samples calculated at once is decreased?
Is this the reason [block~] should always be … 128 64 32 16 8 4 2 1, nothing inbetween, because else it would mess with the calculation every 64 samples?
How do I know which messages are handeled inbetween smaller blocksizes the 64 and which are not?

How does [vline~] execute?
Does it calculate between sample 64 and 65 a ramp of samples with a delay beforehand, calculated in samples, too - running like a "stupid array" in audio-rate?

While sample 1-64 are running, PD does audio only?

[metro 1 1 samp]

How could I have known that? The helpfile doesn't mention this. EDIT: yes, it does.
(Offtopic: actually the whole forum is full of pd-vocabular-questions)
How is this calculation being done?
But you can „use“ the metro counts every 64 samples only, don't you?

Is the timing of [metro] exact? Will the milliseconds dialed in be on point or jittering with the 64 samples interval?
Even if it is exact the upcoming calculation will happen in that 64 sample frame!?

“Ive been getting back into Pd lately and have been messing around with some granular stuff. A few years ago I posted a [vphasor.mmb~] abstraction that made the phase reset of [phasor~] sample-accurate using vanilla objects. Unfortunately, I'm finding that with pitch-synchronous granular synthesis, sample accuracy isn't accurate enough. There's still a little jitter that causes a little bit of noise. So I went ahead and made an external to fix this issue, and I know a lot of people have wanted this so I thought I'd share. 
[vphasor~] acts just like [phasor~], except the phase resets with subsample accuracy at the moment the message is sent. I think it's about as accurate as Pd will allow, though I don't pretend to be an expert C programmer or know Pd's api that well. But it seems to be about as accurate as [vline~]. (Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)
[…]
“
  • c)
    :yellow_heart: :blue_heart: :green_heart:
    Later I discovered that PD has jittery Midi because it doesn't handle Midi at a higher priority then everything else (GUI, OSC, message-domain ect.)

EDIT:
Tryed roundtrip-midi-messages with -nogui flag:
still some jitter.
Didn't try -nosleep flag yet (see below)

  • d)
    :fire:
    So I looked into the sources of PD:

scheduler with m_mainloop()
https://github.com/pure-data/pure-data/blob/master/src/m_sched.c

And found this paper

Scheduler explained (in German):

https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view

wich explains the interleaving of control and audio domain as in the text of @seb-harmonik.ar with some drawings
plus the distinction between the two (control vs audio / realtime vs logical time / xruns vs burst batch processing).
And the "timestamping objects" listed below.

And the mainloop:

Loop
- messages (var.duration)
- dsp (rel.const.duration)
- sleep

With
[block~ 1 1 1]
calculations in the control-domain are done between every sample? But there is still a 64 sample interval somehow?
Why is [block~ 1 1 1] more expensive? The amount of data is the same!? Is this the overhead which makes the difference? Calling up operations ect.?

Timing-relevant objects
from iemlib:

[...]
iem_blocksize~   blocksize of a window in samples
iem_samplerate~  samplerate of a window in Hertz 


------------------ t3~ - time-tagged-trigger --------------------
-- inputmessages allow a sample-accurate access to signalshape --
t3_sig~          time tagged trigger sig~
t3_line~         time tagged trigger line~


--------------- t3 - time-tagged-trigger  ---------------------
----------- a time-tag is prepended to each message -----------
----- so these objects allow a sample-accurate access to ------
---------- the signal-objects t3_sig~ and t3_line~ ------------
t3_bpe           time tagged trigger break point envelope
t3_delay         time tagged trigger delay
t3_metro         time tagged trigger metronom
t3_timer         time tagged trigger timer

[...]

What are different use-cases of [line~] [vline~] and [t3_line~]?
And of [phasor~] [vphasor~] and [vphasor2~]?

When should I use [block~ 1 1 1] and when shouldn't I?

[line~] starts at block boundaries defined with [block~] and ends in exact timing?
[vline~] starts the line within the block?
and [t3_line~]???? Are they some kind of interrupt? Shortcutting within sheduling???

  • c) again)
    :airplane:

https://forum.pdpatchrepo.info/topic/1114/smooth-midi-clock-jitter/2

I read this in the html help for Pd: 
„
MIDI and sleepgrain
In Linux, if you ask for "pd -midioutdev 1" for instance, you get /dev/midi0 or /dev/midi00 (or even /dev/midi). "-midioutdev 45" would be /dev/midi44. In NT, device number 0 is the "MIDI mapper", which is the default MIDI device you selected from the control panel; counting from one, the device numbers are card numbers as listed by "pd -listdev."
The "sleepgrain" controls how long (in milliseconds) Pd sleeps between periods of computation. This is normally the audio buffer divided by 4, but no less than 0.1 and no more than 5. On most OSes, ingoing and outgoing MIDI is quantized to this value, so if you care about MIDI timing, reduce this to 1 or less.
„

Why is there the „sleep-time“ of PD? For energy-saving??????
This seems to slow down the whole process-chain?

Can I control this with a startup flag or from withing PD? Or only in the sources?

There is a startup-flag for loading a different scheduler, wich is not documented how to use.

  • e)
    :walking:
    [pd~] helpfile says:
ATTENTION: DSP must be running in this process for the sub-process to run. This is because its clock is slaved to audio I/O it gets from us!

Doesn't [pd~] work within a Camomile plugin!?

How are things scheduled in Camomile? How is the communication with the DAW handled?

EDIT:

clk – Syncable clocking objects for Pure Data and Max
This library implements a number of objects for highly precise and persistently stable timing, e.g. for the control of long-lasting sound installations or other complex time-related processes.

Sorry for the mess!
Could you please help me to sort things a bit? Mabye some real-world examples would help, too.

:cat2:

posted in technical issues
Internal error.

Oops! Looks like something went wrong!