thank you, @timothyschoen ! unfortnately this did not work.
after commenting out the parts from your post i still got an error related to [pdlink~]

[ 25%] Built target parabolic_tilde
[ 25%] Building C object CMakeFiles/pdlink_tilde.dir/Source/Audio/pdlink~.c.o
In file included from /home/gregor/pd-else-v.1.0-rc12/Source/Audio/pdlink~.c:9:
/home/gregor/pd-else-v.1.0-rc12/Source/Shared/opus_compression.h:1:10: fatal error: opus.h: No such file or directory
    1 | #include <opus.h>
      |          ^~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/pdlink_tilde.dir/build.make:76: CMakeFiles/pdlink_tilde.dir/Source/Audio/pdlink~.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:3596: CMakeFiles/pdlink_tilde.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

I tried to just move the pdlink~.c file out of the source folder but then got errors for [pdlink]

[ 59%] Built target panic
[ 59%] Building C object CMakeFiles/pdlink.dir/Source/Control/pdlink.c.o
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:20:5: error: unknown type name ‘t_link_handle’
   20 |     t_link_handle x_link;
      |     ^~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_anything’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:45:5: warning: implicit declaration of function ‘link_send’ [-Wimplicit-function-declaration]
   45 |     link_send(x->x_link, (size_t)len, buf);
      |     ^~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_receive_loop’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:79:9: warning: implicit declaration of function ‘link_discover’ [-Wimplicit-function-declaration]
   79 |         link_discover(x->x_link);
      |         ^~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:81:25: warning: implicit declaration of function ‘link_get_num_peers’ [-Wimplicit-function-declaration]
   81 |         int num_peers = link_get_num_peers(x->x_link);
      |                         ^~~~~~~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:84:13: error: unknown type name ‘t_link_discovery_data’
   84 |             t_link_discovery_data data = link_get_discovered_peer_data(x->x_link, i);
      |             ^~~~~~~~~~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:84:42: warning: implicit declaration of function ‘link_get_discovered_peer_data’ [-Wimplicit-function-declaration]
   84 |             t_link_discovery_data data = link_get_discovered_peer_data(x->x_link, i);
      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:85:27: error: request for member ‘sndrcv’ in something not a structure or union
   85 |             if(strcmp(data.sndrcv, x->x_name->s_name) == 0) {
      |                           ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:87:45: error: request for member ‘ip’ in something not a structure or union
   87 |                 if(x->x_local && strcmp(data.ip, "127.0.0.1") != 0) continue;
      |                                             ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:88:46: error: request for member ‘ip’ in something not a structure or union
   88 |                 if(!x->x_local && strcmp(data.ip, "127.0.0.1") == 0) continue;
      |                                              ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:90:31: warning: implicit declaration of function ‘link_connect’ [-Wimplicit-function-declaration]
   90 |                 int created = link_connect(x->x_link, data.port, data.ip);
      |                               ^~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:90:59: error: request for member ‘port’ in something not a structure or union
   90 |                 int created = link_connect(x->x_link, data.port, data.ip);
      |                                                           ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:90:70: error: request for member ‘ip’ in something not a structure or union
   90 |                 int created = link_connect(x->x_link, data.port, data.ip);
      |                                                                      ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:93:71: error: request for member ‘hostname’ in something not a structure or union
   93 |                    post("[pdlink]: connected to:\n%s\n%s:%i\n%s", data.hostname, data.ip, data.port, data.platform);
      |                                                                       ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:93:86: error: request for member ‘ip’ in something not a structure or union
   93 |                    post("[pdlink]: connected to:\n%s\n%s:%i\n%s", data.hostname, data.ip, data.port, data.platform);
      |                                                                                      ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:93:95: error: request for member ‘port’ in something not a structure or union
   93 |                    post("[pdlink]: connected to:\n%s\n%s:%i\n%s", data.hostname, data.ip, data.port, data.platform);
      |                                                                                               ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:93:106: error: request for member ‘platform’ in something not a structure or union
   93 |                    post("[pdlink]: connected to:\n%s\n%s:%i\n%s", data.hostname, data.ip, data.port, data.platform);
      |                                                                                                          ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:96:20: error: request for member ‘hostname’ in something not a structure or union
   96 |             if(data.hostname) free(data.hostname);
      |                    ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:96:40: error: request for member ‘hostname’ in something not a structure or union
   96 |             if(data.hostname) free(data.hostname);
      |                                        ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:97:20: error: request for member ‘sndrcv’ in something not a structure or union
   97 |             if(data.sndrcv) free(data.sndrcv);
      |                    ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:97:38: error: request for member ‘sndrcv’ in something not a structure or union
   97 |             if(data.sndrcv) free(data.sndrcv);
      |                                      ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:98:20: error: request for member ‘platform’ in something not a structure or union
   98 |             if(data.platform) free(data.platform);
      |                    ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:98:40: error: request for member ‘platform’ in something not a structure or union
   98 |             if(data.platform) free(data.platform);
      |                                        ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:99:20: error: request for member ‘ip’ in something not a structure or union
   99 |             if(data.ip) free(data.ip);
      |                    ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:99:34: error: request for member ‘ip’ in something not a structure or union
   99 |             if(data.ip) free(data.ip);
      |                                  ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:103:9: warning: implicit declaration of function ‘link_ping’ [-Wimplicit-function-declaration]
  103 |         link_ping(x->x_link, x, pdlink_connection_lost);
      |         ^~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:106:5: warning: implicit declaration of function ‘link_receive’; did you mean ‘pdlink_receive’? [-Wimplicit-function-declaration]
  106 |     link_receive(x->x_link, x, pdlink_receive);
      |     ^~~~~~~~~~~~
      |     pdlink_receive
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_free’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:113:19: warning: implicit declaration of function ‘link_free’; did you mean ‘pdlink_free’? [-Wimplicit-function-declaration]
  113 |     if(x->x_link) link_free(x->x_link);
      |                   ^~~~~~~~~
      |                   pdlink_free
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_set’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:151:17: warning: implicit declaration of function ‘link_init’ [-Wimplicit-function-declaration]
  151 |     x->x_link = link_init(x->x_name->s_name, pd_platform, x->x_local, 7680412);
      |                 ^~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:155:19: warning: assignment to ‘int’ from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
  155 |         x->x_link = NULL; // TODO: handle this state!
      |                   ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_new’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:163:15: warning: assignment to ‘int’ from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
  163 |     x->x_link = NULL;
      |               ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:200:42: warning: implicit declaration of function ‘link_get_own_ip’ [-Wimplicit-function-declaration]
  200 |         post("[pdlink]: own IP:\n%s:%i", link_get_own_ip(x->x_link), link_get_own_port(x->x_link));
      |                                          ^~~~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:200:70: warning: implicit declaration of function ‘link_get_own_port’ [-Wimplicit-function-declaration]
  200 |         post("[pdlink]: own IP:\n%s:%i", link_get_own_ip(x->x_link), link_get_own_port(x->x_link));
      |                                                                      ^~~~~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/pdlink.dir/build.make:76: CMakeFiles/pdlink.dir/Source/Control/pdlink.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:7756: CMakeFiles/pdlink.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

i hope this helps to make it work

Hi, it's been a while, here we go:

RELEASE NOTES:

Hi, it's been almost 8 months without an update and I never took this long!!! So there's a lot of new stuff to cover, because it's not like I've been just sleeping around

The reason for the delay is that I'm trying to pair up with the release cycles of PlugData and we're having trouble syncing up. PlugData 0.9.0 came out recently after a delay of 6 months and we couldn't really sync and pair up then... we had no luck in syncing for a new update now, so now I'm just releasing it up cause enough is enough, and hopefully in the next plugdata release we can sync and offer the same version.

As usual, the development pace is always quite busy and I'm just arbitrarily wrapping things up in the middle of adding more and more things that will just have to wait.

First, I had promised support for double precision. I made changes so we can build for it, but it's not really working yet when I uploaded to deken and tested it. So, next time?

And now for the biggest announcement: - I'm finally and officially releasing a new pack as a submodule, which is a set of abstractions inspired by EuroRack Modules, so I'm thinking of VCV like things but into the Pd paradigm. Some similar stuff has been made for Pd over the years, most notably and famously "Automatonism", but I'm really proud of what I'm offering. I'm not trying to pretend Pd is a modular rack and I'm taking advantage of being in Pd. I'm naming this submodule "Modular EuroRacks Dancing Along" (💩 M.E.R.D.A 💩) and I've been working on it for a year and a half now (amongst many other things I do). PlugData has been offering this for a while now, by the way. Not really fully in sync though.

MERDA modules are polyphonic, thanks to multichannel connections introduced in Pd 0.54! There are 20 modules so far and some are quite high level. I'm offering a PLAITS module based on the Mutable Instruments version. I have a 6-Op Phase Modulation module. A "Gendyn" module which is pretty cool. I'm also including an "extra" module that is not really quite a modular thing at all but fits well called "brane", which was a vanilla patch I first wrote like 15 years ago and is a cool granular live sampler and harmonizer. You'll also find the basics, like oscillators, filters, ADSR envelope and stuff I'm still working on. Lastly, a cool thing is that it has a nice presets system that still needs more work but is doing the job so far.

There are ideas and plans to add hundreds more MERDA modules, let's see when and if I can. People can collaborate and help me and create modules that follow the template by the way

Thanks to Tim Schoen, [play.file~] is now a compiled object instead of an abstraction and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS audio file extensions. A new [sfload] object can import these files into arrays (but still needs lots of more work). There are many other player objects in ELSE that can load and play samples but these don't yet support these new formats (hang in there for the next version update).

Tim also worked on new [pdlink] and [pdlink~] objects, which send control and signal data to/from Pd instances, versions and even forks of Pure Data (it's like [send]/[receive] and [send~]/[receive~], all you need is a symbol, no complicated network or OSC configuration!). And yes, it works via UDP between different computers on the same network. And hell yeah, [pdlink~] has multichannel connections support! By the way, you can also communicate to a [pd~] subprocess. This will be part of ELSE and PlugData of course, and will allow easy communication between PlugData and Pd-Vanilla for instance.

The great pd-lib-build system has been replaced for a 'cmake' build process called 'pd.build' by Pierre Guillot. This was supposed to simplify things. Also, the [sfont~] object was a nightmare to build and with several dependencies that was simply hell to manage, now we have a new and much simpler system and NO DEPENDENCIES AT ALL!!! Some very rare file formats with obscure and seldom sound file extensions may not work though... (and I don't care, most and the 'sane' ones will work). The object now also dumps all preset information with a new message and backwards compatibility broke a bit

I'm now back to offering a modified version of [pdlua] as part of ELSE, which has recently seen major upgrades by Tim to support graphics and signals! This is currently needed in ELSE to provide a new version of [circle] that needed to be rewritten in lua so it'd look the same in PlugData. Ideally I'd hope I could only offer compiled GUI objects, but... things are not ideal

The lua loader works by just loading the ELSE library, no need for anything "else". I'm not providing the actual [pdlua] and [pdluax] objects as they are not necessary, and this is basically the only modification. Since PlugData provides support for externals in lua, if you load ELSE you can make use of stuff made for PlugData with lua without the need to install [pdlua] in Pd-Vanilla.

For next, we're working on a [lua] object that will allow inline scripting and will also work for audio signals (again, wait for the next version)! Also for the next version, I'm saving Ben Wesch's nice 3d oscilloscope made in lua (it'll be called [scope3d~]). There's a lot going on with the lua development, which is very exciting.

As for more actual new objects I'm including, we have [vcf2~] and [damp.osc~]. The first is a complex one pole resonant filter that provides a damping oscillation for a ringing time you can set, the next is an oscillator based on it. There's also the new [velvet~] object, a cool and multichannel velvet noise generator that you can also adjust to morph into white noise.

I wasn't able to add multichannel capabilities to many existing objects in ELSE in this one, just a couple of them ([cosine~] and [pimp~]). Total number of objects that are multichannel aware now are: 92! This is almost a third of the number of audio objects in ELSE. I think that a bit over half might be a reasonably desired target. More multichannel support for existing objects to come in the next releases.

Total number of objects in the ELSE library is now 551!

As for the Live Electronics tutorial, as usual, there are new examples for new objects, and I made a good revision of the advanced filter section, where I added many examples to better explain how [slop~] works, with equivalent [fexpr~] implementations.

Total number of examples in the Live Electronics Tutorial is now 528!

There are more details of course, and breaking changes as usual, but these are the highlights! For a full changelog, check https://github.com/porres/pd-else/releases/tag/v.1.0-rc12 (or below at this post).

As mentioned, unfortunately, ELSE RC12 is not yet fully merged, paired up and 100% synced in PlugData. PlugData is now at version 0.9.1, reaching the 1.0 version soon. Since ELSE is currently so tightly synced to the development of PlugData, the idea is to finally offer a final 1.0 version of ELSE when PlugData 1.0 is out. Hence, it's getting closer than ever Hopefully we will have a 100% synced ELSE/PlugData release when 0.9.2 is out (with a RC 13 maybe?).

Please support me on Patreon https://www.patreon.com/porres
You can follow me on instagram as well if you like... I'm always posting Pd development stuff over there https://www.instagram.com/alexandre.torres.porres/

cheers

ps. Binaries for mac/linux/windows are available via deken. I needed help for raspberry pi

CHANGELOG:

LIBRARY:

Breaking changes:

• [oscope~] renamed to [scope~]
• [plaits~] changed inlet order of modulation inputs and some method/flags name. If a MIDI pitch of 0 or less input is given, it becomes a '0hz'.
• [gbman~] changed signal output range, it is now filtered to remove DC and rescaled to a sane -1 to 1 audio range.
• [dust~] and [dust2~] go now up to the sample rate and become white noise (removed restriction that forced actual impulses, that is, no conscutive non zero values)
• [cmul~] object removed (this was only used in the old conv~ abstraction to try and reduce a bit the terrible CPU load)
• [findfile] object removed (use vanilla's [file which] now that it has been updated in Pd 0.55-0)
• [voices] swapped retrig modes 0 and 1, 'voices' renamed to 'n', now it always changes voice number by default as in [poly] (this was already happening unintentionally as a bug when one voice was already taken). The 'split' mode was removed (just use [route], will you?)
• [voices~] was also affected by changes in [voices] of course, such as 'voices' message being renamed to 'n'.
• [sr~]/[nyquist] changed output loading time to 'init' bang
• [sample~] object was significantly redesigned and lots of stuff changed, new messages and flags, added support for 64-bit audio files (Pd 0.55 in double precision and ELSE compiled for 64 bits is required for this). Info outlet now also outputs values for lenght in ms and bit depth.
• [sfont~] uses now a simpler build system and this might not load very very rare and unusual sound formats.

Enhancements/fixes/other changes:

• builds for double precision is now supposedly supported, by the way, the build system was changed from pd-lib-builder to pd.build by Pierre Guillot.
• [play.file~] is now a compiled object instead of an abstraction thanks to Tim Schoen, and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS file extensions.
• Support for double precision compilation was improved and should be working for all objects (not yet providing binaries and fully tested yet by the way).
• The ELSE binary now loads a modified version of [pdlua], but no [pdlua] and [pdluax] objects are provided.
• added signal to 2nd inlet of [rm~].
• fixed 'glide' message for [mono~].
• fixed [voices] consistency check bug in rightmost outlet and other minor bugs, added flags for 'n', 'steal' and offset.
• [gain~] and [gain2~] changed learn/forget shortcut
• [knob] fixed sending messages to 'empty' when it shouldn't, ignore nan/inf, prevent a tcl/tk error if lower and upper values are the same; added "learn/forget" messages and shortcut for a midi learn mechanism.
• [mpe.in] now outputs port number and you can select which port to listen to.
• Other MIDI in objects now deal with port number encoded to channel as native Pd objects. Objects affected are [midi.learn], [midi.in], [note.in], [ctl.in], [bend.in], [pgm.in], [touch.in] and [ptouch.in].
• [pi]/[e] now takes a value name argument.
• [sr~]/[nyquist~] take clicks now and a value name argument.
• fixed phase modulation issues with [impulse~] and [pimp~].
• [cosine~] fixed sync input.
• added multichannel features to [cosine~] and [pimp~].
• [plaits~] added a new 'transp' message and a functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]), fixed MIDI velocity.
• [pluck~] added a new functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]).
• 26 new objects, [velvet~], [vcf2~], [damp.osc~], [sfload], [pdlink] and [pdlink~], plus abstractions from a newly included submodule called "Modular Euro Racks Dancing Along" (M.E.R.D.A)! Warning, this is all just very very experimental still, the object are: [adsr.m~], [brane.m~], [chorus.m~], [delay.m~], [drive.m~], [flanger.m~], [gendyn.m~], [lfo.m~], [phaser.m~], [plaits.m~], [plate.rev.m~], [pluck.m~], [pm6.m~], [presets.m], [rm.m~], [seq8.m~], [sig.m~], [vca.m~], [vcf.m~] and [vco.m~] (6 of these are multichannel aware).

Objects count: total of 551 (307 signal objects [92 of which are MC aware] and 244 control objects)!

• 311 coded objects (203 signal objects / 108 control objects
• 240 abstractions (104 signal objects / 136 control objects)

TUTORIAL:

• New examples and revisions to add the new objects, features and breaking changes in ELSE.
• Added a couple of examples for network communication via FUDI and [pdlink]/[pdlink~]
• Section 36-Filters(Advanced) revised, added more examples and details on how [slop~] works.
• Total number of examples is now 528!

@jameslo said:

Honestly, I didn't know if that was @fintg's requirement,

It's certainly a reasonable guess. If the requirement instead were "I just played something cool; write the last 10 seconds to disk" you can do that without a circular buffer at all.

I was just surprised and annoyed that one can only access the delay line's internal buffer at audio rate (and was hoping that someone would prove me wrong).

Access to the internal buffer wouldn't be very useful without also knowing the record-head position. In that case delwrite~ would need an outlet for the current frame being written.

That would actually be a very nice feature request.

In SuperCollider as well, DelayN, DelayL and DelayC don't give you access to the internal buffer. But you can create your own buffer and write into it, with total control over phase, with BufWr -- and, because you control the write phase, you already know what it is. It's quite nice way to do it.

Basically the lack of ipoke~ in vanilla causes some headaches.

Look at the hoops I have to jump through! The extra memory I have to use!

I don't think there is any way to do this without using some extra memory.

In a circular buffer, you have:

|~~~~~~ new audio ~~~~~~|~~~~~~ old audio ~~~~~~|
                        ^ record head

When you write to disk, naturally you want the old audio earlier in the file. There are only two ways to do that. One is to write the "old" chunk without closing the file, and append the "new" chunk, and then close the file.

In SC, if I know the record head position, I'd do it like:

buf.write(path, "wav", "int24", startFrame: recHead, leaveOpen: true, completionMessage: { |buf|
    buf.writeMsg(path, "wav", "int24", numFrames: recHead, startFrame: 0, leaveOpen: false)
});

AFAICS Pd does not support this, so you're left with duplicating new after old data. (FWIW, though, there's plenty of memory in modern computers; I wouldn't lose sleep over this.)

Then there is the problem of synchronous vs asynchronous disk access. AFAICS Pd's disk access is synchronous, and because the control layer is triggered from the audio loop, slow disk access could cause audio dropouts. OS file system caching might reduce the risk of that, but you never know. Ross Bencina's article about real-time audio performance advises against time-unbounded operations in the audio thread.

SC's buffer read/write commands run in a lower priority thread; wrt audio, they are asynchronous. This is good for audio stability, but it means that, by the time you get around to writing, the record head has moved forward. So, even though I could do the two-part write easily, I'd get a few ms of new data at the start of the file. I think I would solve that by allocating an extra, say, 2 seconds and then just don't write the 2 seconds after the sampled-held recHead value: startFrame: recHead + (s.sampleRate * 2). (If it takes 2 seconds to write a 10 second audio file, then you have bigger problems than circular buffers.) Then the record head can move freely into that zone without affecting audio written to disk.

hjh

@fina said:

I'm especially worried about multi mapping the controls to different pages/layers and how the controllers behave if the pot/encoder is in a different position

This can be a pain, faders (unless they are motorized) will jump, if you are at midi value 10 and switch too a different mapping that has that fader at max, when you move it it will jump down to 10, quite annoying but can be exploited and was a common trick on the early synths with patch memory that used analog controls, but this was generally more a hindrance than a help. Most modern controllers use endless rotary encoders which will update their values, in absolute mode you map out the controls on the controller itself and make presets, switch the mapping and the new values are there so no jump when you turn the knob but this has the disadvantage that they generally are limited to the low resolution 0-127 midi values. In relative mode the encoder sends only a plus or minus value so you can have unlimited resolution but you need to do more in pd since you need to add or subtract those plus or minus values from a stored value.

Personally I find mapping controls on a controller to be slow and I do need greater resolution so I do it all the mapping and the like in pd with relative mode, I made some abstractions to take care of all the work and they do some useful things like the first tick is ignored and just highlights the parameter being edited so when you forget what knob does what you can find your way without altering anything that is going on. This also means you are not limited by the controllers memory for mappings, I just do that in the patch so I have a virtually unlimited number of mappings. I use an Arturia Beatstep as a controller, 16 pads and 16 encoders, so each pad selects a mapping giving me 256 parameters I can edit or if I somehow needed more I could arrange the pads as 8 banks of 8 and 1024, but I have yet to need to do that. It also has the sequencer mode which is very limited but handy as an easy way to easily test sounds out. I can upload these abstractions if you decide on going with relative encoders, been on my list to get those uploaded but I tend to drag my feet on documentation so they have yet to get a proper upload, they have been uploaded a few times in various threads just not everything with actual documentation.

One thing to keep in mind, some controllers have software editors to make it easier to map stuff out, these software editors often do not work in linux even in Wine, so if you use linux you will want to make sure that the sysex commands have been published either by the maker or by someone who has sat down and figured them all out. For what ever reason some companies just will not release the sysex (Arturia being one of them). It is not terribly difficult to figure out the sysex on your own, just time consuming.

Hey there! I'm trying to find a good and versatile midi controller for pd in general, to get more tactile and hands-on controls for different patches. While researching I stumbled upon lots of different controllers in different price ranges, starting with fader/pot controllers like the korg nanokontrol or novation launchcontrol (xl), midi keyboards like the arturia keylab/minilab and akai mpk (mini), or endless encoders like behringer x-touch (mini), faderfox uc4/ec4, or the intech grid controllers.
I'm always struggling with decisions and therefore thought about asking for your experiences. I'm especially worried about multi mapping the controls to different pages/layers and how the controllers behave if the pot/encoder is in a different position. so if you'd like to talk a bit about your experiences with midi controllers, what works best for you, what you think is important to consider, and how you implement midi controllers in your patches and/or performances, I'd be very thankful!
Kind regards, f.

Hey everybody,

Sorry, for a lot of text. But the bold text at the bottom is my main question. The rest will help you to get a better understanding of my situation.

you helped me so much, with my last question here (the Faders are working dope now):
https://forum.pdpatchrepo.info/topic/13849/how-to-smoothe-out-arrays/25

I am doing a Steinberg Houston to Mackie Control emulation at the moment, to use my controller with other DAWs than Cubase/Nuendo. Will upload it to the internet community, when I am finished for the handful of people that maybe are also using this controller.

I made good progress:

I got the Faders and the normal knobs to work. And the display puts out information. But it is with bugs, because the LCD Screen of the Houston has 40 characters for one line and the Mackie Universal Pro has 56 Characters. So i did a list algorithm, which deletes spaces of the mackie message until the message fits on the 40 character line. Maybe there is a method wich will work better but this subject eats too much time for me at the moment and it works rough okay. One defenitely get's some helpful information on the screen from the DAW.

The Faders and Rotary Knobs and normal knobs are the most important of this controller I guess. The Faders are working fine as I mentioned above, but there is a problem with the rotary knobs, wich I can't handle alone and hope you can help me.

The problem is, that the Mackie Controller send simple clicks to the DAW. If you are turning a rotary knob, it sends out a number of midi messages:
If you turn it right, it sends midi messages wich contains the value 1 and if you turn it down it sends messages wich are containing the value 65.
"When the VPots are rotated rapidly, a message equal to the number of clicks is sent."

BUT the Houston controller instead is sending values like it's faders with 15 (MSB) and 128(LSB) values. AND it is updating the rotary limit by itself. So if I turn a rotary, it will update it's LEDs and stops sending midi messages when it reaches the maximum or minimum value. So, I did this patch as a momentary state:

Rotary Encoder Example.pd

The DAW sends 11 values for the Houston LEDs. 11 is max and 1 is min. This is good, I send this values to my houston controller and can update the rotary values and LEDs.
With this updated values from the DAW, I can force my rotary knobs, that they don't stop to send values, because they are set to the values, which the DAW sends, every time I turn a knob. With this method I got it to work to imitate a Mackie Rotary knob. Everytime the Houston Rotary value changes, it sends Mackie "midi click values" according to the amount of midi value changes of the houston.
BUT the problem is, that this is working only in one direction. Now my main question:

How can I make pure Data know, if I am turning my knob in the left direction or in the right direction? There is also the problem, which I mentioned above, that I set the momentary value everytime, I move the rotary, so that I get a unlimited amount of possible rotary move "clicks". Also the midi values which the houston sends arent perfect smooth. It works fine, but it isn't like that, that if you move a rotary in one direction, every value one by another is perfectly lower or higher.

I think I maybe need a algorythm, which looks if the values in a time period are getting higher or lower and then send out bangs on two seperate outlets. For example the left outlet for lower values and the right outlet for higher values. And it should also detect, if I move the rotary fast or slow. So a constant smoothing or clocked bang is also not an option. This is defenitely to complicated for me. I have no idea and what I tried didn't worked.

Would be super cool, if you could help me out again.

@lacuna said:

Hard to tell without more details. I also have no experience with motorfader-hacks, but am interested.
At a precision of 1600 values it is very likely some subtle hardware bouncing, resonance of motor, dirt or similar ?
How slow do you drive them?
I would maybe try to eleminate the discontinuity on the hardware / measurement side, instead of cheating.
Do several measurements, instead of one shot only.
Also try to drive it from Pd instead of Cubase. Very slowly. Calibrating. Remember, there is some latency, too.

Anyway, this is what you where asking for, I think:
new romantics )

align_up_down_3c.pd

@lacuna Hey, thank you very much, for your help and the patch!

I will now describe more precisely, what I would like to do. I thought, it would be a little bit off topic, because it is a bigger project.

Also, I think, I described it not correctly with the motorfader recording. That isn't true. My english is not the best, so my formulations arent always on point, but I will try my best.

So, to describe my Project, I am working on:

I have an old 20 years old "Steinberg Houston" Midi-Controller, which works via the Mackie Protocoll. It was specifically designed as a Cubase / Nuendo Controller back in the days. Cubase / Nuendo are also, as far as I know, the only DAWs with which the controller is working nowadays.

Almost all DAWs are supporting the specifications of a "Mackie Universal Pro" Controller. So I would like to program a Midi-Data Converter, so I can use my controller with other DAWs as a "Mackie Universal Pro" Controller.

At the moment I already found out, which midi Data the faders send and which midi data the DAW Cubase sends to the Controller. I also converted the Midi Data, so that I can use the controller faders, while Cubase thinks, it is a Mackie Universal Pro.

So, but the problem, why I started this thread is, that I noticed, that the Mackie Controller needs to get different values from the DAW to get the right fadermovement done, than my Steinberg Houston. For example: When I set my Fader in the DAW to 6 dBFS, my Conroller Fader moves correctly to 6 dBFS, as that is the highest fader value in Cubase. Also the other way around. If I set the Fader in Cubase to -00 dBFS, also my Fader of the controller is at the right position. So the lowest and highest values are correct. But if I set -20 dBFS in Cubase via Mackie UP Mode, my controller sets the fader to -10 dBFS. In the original Cubase "Steinberg Houston" mode, the fader movements are very precise and always are reflecting the number, which I set in the mixer in Cubase.

So my Idea was, to first send all Pitchbend values from Pure Data via Midi to Cubase in Houston Mode. I tricked Cubase in thinking, I would use the Houston Controller, but used Pure Data instead, to be very precise. Then in the preferences of cubase, I deleted all automation smoothing and set up a tempo in Cubase and with Metro in Pure Data, so that each 8th note, one pitch bend value is send to Cubase. and I synchronised both my DAW Cubase and Pure Data with a C3, sent from Cubase, when I start the Playback in Cubase. This C3 is then sent to Pure Data and than acts as a bang in PD to start the metro and sends the Midi Values. This midi Values are written then in Cubase as a Automation.

Then after that, I did the same process again, and recorded the Automation Values in Pure Data. But these values arent as smoothe as I would like to have them, even I recorded them that slow, that I set a metro of 8 per second which is for the 14 Bit values something like half an hour. The faders are the most important feature of my Controller for me, so I take the right amount of time to get them very precisely.

Between: I also found out the SysEx values to display what I want on my two rows houston display with Pure Data which was fun.

@eulphean said:

I'm using pure data on a raspberry pi 3+ for a project. I have bluetooth configured properly on it. I can send regular audio to bluetooth speaker connected, but the preferences -> audio in PureData doesn't show the bluetooth speaker. It only shows internal audio card or if I have a USB audio card, that shows too. But no bluetooth device.

How do I configure that? Do I need to use jack or something to route audio to bluetooth for Pd?

My experience with Bluetooth audio in Linux has been:

• JACK has zero tolerance for the audio driver ever being late -- expect crashes or system lockups if you try to route audio from JACK to Bluetooth. That is, just don't.

• PulseAudio's support for BT audio is pretty good -- the "regular audio" that you spoke of. Audio production apps typically bypass PulseAudio, in which case BT audio may simply not be supported for them. That is, I expect you'd hit the same problem with SuperCollider, Audacity, Ardour, VCV Rack etc etc etc.

I'm not aware of a solution... That's not to say that there absolutely isn't one, but the Linux audio space is not unified as it is in Mac so audio device support may not be universal.

hjh

According to block~ help, if you bang [switch~] it runs one block of DSP computations, which is useful for performing computations that are more easily expressed as audio processing. Something I read (which I can't find now) left me with the impression that it runs faster than normal audio computations, i.e. as if it were in control domain. Here are some tests that confirm it, I think: switch~ bang how fast.pd

The key to this test is that all of the bangs sequenced by [t b b b b] run in the same gap between audio block computations. When [switch~] is banged, [osc~] fills array1, but you can see that element 63 of array1 changes after [switch~] is banged. Furthermore, no logical time has elapsed. So it appears that one block of audio processing has occurred between normal audio blocks. [bang~] outputs when that accelerated audio block processing is complete.

This next test takes things further and bangs [switch~] 10 times at control rate. Still, no logical time elapses, and [bang~] only outputs when all 10 bangs of [switch~] are complete. [rzero_rev~ 0] is just an arcane way of delaying by one sample, so this patch rotates the contents of array1 10 samples to the right. switch~ bang how fast2.pd

(There are better ways to rotate a table than this, but I just needed something to test with. Plus I never pass up a chance to use [rzero_rev~ 0] )

Finally, I've seen some code that sends a 1 to [switch~] and then sends 0 after one block of processing. In this test you can see that one block of audio is processed in one block of logical time, i.e. the normal way. switch~ bang how fast3.pd

But that second test suggests how you could embed arbitrary offline audio processing in a patch that's not being run with Pd's -batch flag or fast-forwarded with the fast-forward message introduced in Pd 0.51-1. Maybe it's an answer to two questions I've seen posted here: Offline analysis on a song and Insant pitch shift. Here's a patch that writes 20s of 440 Hz to a file as fast as possible (adapted from @solipp's patch for the first topic). You just compute how many blocks you need and bang away. write440File.zip

Here's another that computes the real FFT of an audio file as fast as possible: loadFFT.zip

But as with any control rate processing, if you try to do too much this way, Pd will fall behind in normal audio processing and stutter (e.g. listen to the output while running that last patch on a >1 minute file). So no free lunch, just a little subsidy.

I searched through many of the s~/r~ throw~/catch~ hops in my own code for mistakes based on what I've learned, and it looks like ~50% of all my non-local audio connections carry modulation signals that originate from control rate objects, so those aren't affected much. Only a few programs would have been broken had the non-local connections not matched, but because things were created in signal-flow order where it mattered, there was a consistent (and often unnecessary) 1 block delay everywhere. Many of those patches were later converted to use tabsend~/tabreceive~ under a small block size, and a few were converted to use delay lines. I was burned by the creation order side effect of delwrite~/delread~ once, but it wouldn't have happened had I not taken a lazy shortcut. Hilariously, I also found one test patch that I used to declare definitively, once and for all, that s~/r~ always introduces a 1 block delay if the sort order isn't controlled using the G05 technique. To paraphrase Agent K in the movie Men in Black, imagine what I'll "know" tomorrow!

So as a practical issue, I doubt coders are getting tripped up by this frequently. If you're like me you tend to code in signal flow order, and so you are mostly just introducing latency unnecessarily. RE advice, I agree with @Nicolas-Danet: use local audio connections wherever it matters and never mind the clutter. Even my worst spider web isn't so bad. Subpatches and abstractions can help hide the mess.

But when things are broken and showtime is looming, you'd be foolish not to use what you know, especially when you can always go back after curtain calls and adjust things to satisfy the style police. Here is a summary of the sort rules as best as I've been able to figure them out so far:

• A patch orders its constituent audio subpatches and abstractions, but has no influence over their internal ordering. Consequently, these rules are applied starting at the top level patch and recurse into each subpatch and abstraction.
• Audio chain tributaries and independent audio chains are executed in reverse order of their head's creation, except for those created by [clone], which are executed in the order of their creation (i.e. ascending clone index order).
• Audio branches that start from fanout connections are executed in reverse order of their start connection's creation.
• Whenever the rules conflict, the rule that places the tilde object the latest in line takes precidence.

These sort rules can affect your patch because unless s~ and throw~ buffer their data before their corresponding r~ and catch~ are executed, the latter will have to wait a block to access it. Delread~ will have a minimum 1 block delay.

Finally, I thought of this technique if you're absolutely certain you are going to get burned (or are just paranoid): wrap all s~, r~, throw~, catch~, delwrite~, delread~, and audio chain heads in their own subpatches. I noticed that if you modify the contents of a subpatch, it doesn't change its sort order in the containing patch, so you can add test code (e.g. [sig~ <uniqueNr>]->[tabsend~ <sharedArray>]) to subpatch pairs and check their execution order without changing it. If the order is wrong, then you cut and repaste the appropriate subpatches or audio connections according to the rules above until it isn't. That should take 15 mins, not days.