@raynovich said:

Does ofelia take over the "terminal" or some other function for Pure Data if created?

TL;DR Probably the best solution is for you to construct the commands with full paths, pointing exactly where you want, and do not rely on the current working directory.

I.e. not cd xxx/yyy/zzz && ls, but ls xxx/yyy/zzz.

Why?

"Shell" functions (as I understand it -- maybe it's different in some programming environments, but this is my observation) generally don't persist their state.

That is, if you open a terminal window, there is one shell, and every command operates on the same shell. cd changes the current working directory of the shell, and the next command remembers the new cwd.

An object like [shell] is like opening a new terminal window for every command. Every invocation starts from scratch. So you should not expect it to work if you ask shell to first cd, then ls. (You said this worked, but I was not able to get that behavior on my machine.)

SuperCollider has a couple of ways to do it that illustrate the issues involved.

"ls".unixCmd;  // user home

"cd tmp".unixCmd;  // no output, OK

"ls".unixCmd;  // still user home

The cd did not affect the second ls -- because it's like: terminal window 1, ls; terminal window 2, cd; terminal window 3, ls and why would you expect window 2 to affect the behavior of window 3?

Many shells, when parsing the typed input, can handle a series of commands separated by &&:

"cd tmp && ls".unixCmd;  // lists ~/tmp, OK!

But this is a parsing feature. If a backend issues the command in a different way -- as an array of strings, where the first string is the command and the other strings are arguments, one by one -- this bypasses the parser (because the arguments are already parsed into the array), and the && trick no longer works.

"cd tmp && ls".split($ ).postcs.unixCmd;
[ "cd", "tmp", "&&", "ls" ]
(and no `ls` listing)

[shell], as far as I can see, works in this second way. A message like ls tmp works only if it's a list of two symbols. If you try to make it a single command string -- ls\ tmp -- then it fails, because there is no system command named l-s-space-t-m-p. (In SC, "ls tmp".unixCmd runs the command through the shell's parser, which splits a string into command-and-argument. That usage isn't supported in [shell]. Maybe it's supported in [command] but I didn't take a look.)

hjh

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!

There's an experimental 64-bit version of Pd

This is really orthogonal to 64-bit OSC timetags. This version just uses 64-bit floats as the underlying type for float atoms and samples. It does not magically implement the missing OSC typetags. Also, let's please call this the "double-precision" version, as "64-bit" typically refers to the CPU architecture.

Actually, there is no reason why Pd's [oscformat] and [oscparse] could not support the h (= int64) and d (= float64) typetags for sending/parsing OSC message. Of course, single-precision Pd would need to round the values down to 32-bit floats, but double-precision Pd could keep the precision (at least for 64-bit floats; 64-bit integers may still lose some lower bits when converted to 64-bit float atoms).

@ddw_music Beware all....... Yamaha send MSB and LSB in reverse order to everyone else.. see below for how to deal with that....
Also most manufacturers... for low values.... when only 7bits are required they output just the LSB.

You might already be aware of all that.

A byte has 8 bits, bit 0 to bit 7 (0 = cleared or 1 = set).
A MIDI status byte – i.e. what sort of MIDI message it is - always has bit 7 set
A MIDI data byte – i.e. what value - always has bit 7 cleared.
Therefore a data byte can only use the lower 7 bits to determine its value
0 to 127 ($7F) or 0111 1111 (bit 0 is the rightmost 1, bit 7 is 0)
To get a value greater than 127 we join two data bytes together. The rightmost 7 bits from each byte gives a 14 bit number
0111 1111 and 0111 1111 becomes 0011 1111 1111 1111 the top 2 bits (bit14 and bit15) are ignored
So the 14bit number range is0 to 16383 ($3FFF) or 0011 1111 1111 1111(this is just 14 data bits in a 16 bit number – the 2 top (leftmost) bits are always 0).
The two bytes that make up the 14 bit number are what MIDI calls a course adjustment and a fine adjustment.
The byte that does a course adjustment is called the Most Significant Byte (MSB) and the fine adjuster is called the Least Significant Byte (LSB).

Also NRPN can be very slow over midi when data rates are high...... and SYSEX will be much faster.

David.

P.S. I have a lot of old docs and software from the decade before last..... midi stuff.... that has disappeared from the web...... stuff that can change encoder resolution on Behringer BCF units for example, which is not available in the Behringer software or on the hardware.
Just ask.

@whale-av Oh that's great, thanks for the [makefile] trick!
I've tried again to send the message as a list and importing it in different notation tools - both Musescore and lilypond do assume the default 120bpm when I do not send any tempo message (not sure how I got the 190bpm yesterday, I can't reproduce...), and all bars disappear when I inject the tempo message (either as a list or as a stream, which in both cases just add a line 0 255; in [seq] ). Might be a limitation of [seq] itself.

To make that clear, I've updated the default-tempo midi file in Musescore itself to edit the tempo to 89bpm, exported it as midi (reopened it in Lilypond to confirm the tempo is properly interpreted again), and then sent it via [read file_musescore.mid( to [seq] and again [write file.mid( ... Turns out that the tempo information is lost in the transition through [seq], so this probably just means that tempo changes are not supported by [cyclone/seq] ! too bad.

Looking for alternatives, I've found that [mrpeach/midifile] interestingly uses midi ticks.
But I will follow the sequencing tutorial of ELSE instead, and hopefully [else/midi] also supports midi tempo.

@ddw_music said:

I also admit some ignorance here and I suspect we are going to enter the clashing worlds of digital and analog, the brutal absolutes of the digital world are alien to my analog sensibilities where we can just ballpark it and generally get closer to the real world result than the math would get us and get there in a fraction of the time (talking circuit design and the like here, not physics). And like you I am not 100% certain what is meant by warble tone, I based my answer on what was likely to kill a speaker which assumes the salesman that scolded jameslo had a clue.

One of the sines is too low to be audible

How does the amplifier and speaker know what is audible? We can hear the tremolo effect of this beating so the speaker has to be moving at that rate and those tones we hear as tones are moving on top of that beating, the 4hz looks sort of like a carrier frequency as far as the speaker is concerned. Beat frequencies can cause large extension to the point of over extension (voice coil pops out of the gap) and sustained beat frequencies of these low frequency sorts can cause heat to build up in coil faster than it can dissipate it leading to warping. Getting a good strong beat frequency going and feeding it into a speaker with decent extension will let you see that beat frequency, change one oscillator to half or double the frequency of the other so there is no beating and it will barely move, just a nice even tremble. This of course is dependent on the frequency characteristics of the entire setup but generally if you get one of those beat frequencies going that you can feel than you will be able to see it in the speakers movement.

Beating can be produced from any waves, not just sines.

@whale-av said:

@atux If you send the message [dump( into [boids 2d] what value is printed to the Pd console for the "number" parameter?
Sending [number 7( into [boids 2d 15] will make only 7 of them move. The others will be stationary.
So maybe sending in the message [number 115( will get them all moving..?
David.

Hi,

yes, sending the [dump( message into [boids 2d] object and printing the parameter values ​​in the Pd console, I found that the parameter values ​​completely change from those declared in the patch.
The speed changes from 3 to 0.1, so obviously nothing moves.
The maxspeed and inertia also become very small (about 0.2).

However I have added some sliders to control the values ​​directly and more comfortably in realtime, something like this:

...and everything works fine. The behavior is what you wrote in your post.

Thank you,
a.

EDIT
Now I'm trying to figure out how to get the (x,y) coordinates of each boid during motion, in two distinct number boxes for each boid, with a certain time step (as small as possible).
I think I succeeded by doing something like this:

This is the start of the output stream in the pd console:

B0_x: 1.11714
B0_y: -0.154289
B1_x: 0.859991
B1_y: -1.04122
B2_x: 0.988587
B2_y: -0.620997
B3_x: 1.11418
B3_y: -0.829169
B4_x: 0.756241
B4_y: -0.51217
B0_x: 1.12641
B0_y: -0.110254
B1_x: 0.87085
B1_y: -1.0069
B2_x: 0.99647
B2_y: -0.576692
B3_x: 1.14712
B3_y: -0.798511
B4_x: 0.772748
B4_y: -0.480177
B0_x: 1.13585
B0_y: -0.0662551
B1_x: 0.881453
B1_y: -0.972498
B2_x: 1.01429
B2_y: -0.545412
B3_x: 1.17485
B3_y: -0.763067
B4_x: 0.780488
B4_y: -0.445019
B0_x: 1.14541
B0_y: -0.0222838
B1_x: 0.891889
B1_y: -0.938044
B2_x: 1.03125
B2_y: -0.51366
B3_x: 1.19768
B3_y: -0.724288
B4_x: 0.793631
B4_y: -0.411504
B0_x: 1.15512
B0_y: 0.0216567
B1_x: 0.902249
B1_y: -0.903567
B2_x: 1.04731
B2_y: -0.481438
B3_x: 1.21641
B3_y: -0.683373
B4_x: 0.808751
B4_y: -0.378833
B0_x: 1.16492
B0_y: 0.0655764
B1_x: 0.912567
B1_y: -0.869077
B2_x: 1.06238
B2_y: -0.448745
B3_x: 1.23193
B3_y: -0.641134
B4_x: 0.825433
B4_y: -0.346931
B0_x: 1.17478
B0_y: 0.109484
B1_x: 0.922866
B1_y: -0.834582
B2_x: 1.07642
B2_y: -0.415597
B3_x: 1.24506
B3_y: -0.598092
B4_x: 0.843365
B4_y: -0.315715
B0_x: 1.18466
B0_y: 0.153385
B1_x: 0.933166
B1_y: -0.800087
B2_x: 1.08182
B2_y: -0.370922
B3_x: 1.26792
B3_y: -0.559326
B4_x: 0.862311
B4_y: -0.285104
B0_x: 1.19456
B0_y: 0.197283
B1_x: 0.943492
B1_y: -0.7656
B2_x: 1.0977
B2_y: -0.338616
B3_x: 1.28719
B3_y: -0.518661
B4_x: 0.872322
B4_y: -0.250524
B0_x: 1.20446
B0_y: 0.241179
B1_x: 0.953858
B1_y: -0.731124
B2_x: 1.12197
B2_y: -0.312019
B3_x: 1.30357
B3_y: -0.47675
B4_x: 0.874392
B4_y: -0.214584
B0_x: 1.21436
B0_y: 0.285078
B1_x: 0.964273
B1_y: -0.696664
B2_x: 1.13781
B2_y: -0.269901
B3_x: 1.32971
B3_y: -0.440118
B4_x: 0.881343
B4_y: -0.179261
B0_x: 1.22636
B0_y: 0.328448
B1_x: 0.974756
B1_y: -0.662224
B2_x: 1.15208
B2_y: -0.227224
B3_x: 1.35207
B3_y: -0.401068
B4_x: 0.893584
B4_y: -0.145406
B0_x: 1.24059
B0_y: 0.37114
B1_x: 0.985347
B1_y: -0.627817
B2_x: 1.16511
B2_y: -0.184151
B3_x: 1.371
B3_y: -0.360243
B4_x: 0.90793
B4_y: -0.112388
B0_x: 1.25707
B0_y: 0.413011
B1_x: 0.996047
B1_y: -0.593444
B2_x: 1.17717
B2_y: -0.140797
B3_x: 1.38672
B3_y: -0.318079
B4_x: 0.923963
B4_y: -0.0801551
B0_x: 1.27583
B0_y: 0.453915
B1_x: 1.00686
B1_y: -0.559105
B2_x: 1.18852
B2_y: -0.0972526
B3_x: 1.39945
B3_y: -0.274918
B4_x: 0.941362
B4_y: -0.048639
B0_x: 1.29685
B0_y: 0.493706
B1_x: 1.01778
B1_y: -0.524801
B2_x: 1.19942
B2_y: -0.0535927
B3_x: 1.40947
B3_y: -0.231048
B4_x: 0.959882
B4_y: -0.0177685
B0_x: 1.32009
B0_y: 0.53224
B1_x: 1.02881
B1_y: -0.490533
B2_x: 1.218
B2_y: -0.0227568
B3_x: 1.41711
B3_y: -0.186701
B4_x: 0.969484
B4_y: 0.0169276
B0_x: 1.3455
B0_y: 0.56938
B1_x: 1.03996
B1_y: -0.456305
B2_x: 1.23509
B2_y: 0.00892889
B3_x: 1.42272
B3_y: -0.142052
B4_x: 0.981754
B4_y: 0.050772
B0_x: 1.37301
B0_y: 0.604992
B1_x: 1.05125
B1_y: -0.42212
B2_x: 1.242
B2_y: 0.0533949
B3_x: 1.43903
B3_y: -0.100109
B4_x: 0.996152
B4_y: 0.0837672
B0_x: 1.40251
B0_y: 0.638968
B1_x: 1.06267
B1_y: -0.387978
B2_x: 1.24934
B2_y: 0.097793
B3_x: 1.46458
B3_y: -0.0630706
B4_x: 1.00166
B4_y: 0.119344
B0_x: 1.43392
B0_y: 0.671193
B1_x: 1.07422
B1_y: -0.353884
B2_x: 1.2658
B2_y: 0.12981
B3_x: 1.48536
B3_y: -0.0231537
B4_x: 0.999281
B4_y: 0.155266
B0_x: 1.46712
B0_y: 0.701569
B1_x: 1.08593
B1_y: -0.319839
B2_x: 1.28128
B2_y: 0.162308
B3_x: 1.50148
B3_y: 0.0188584
B4_x: 1.00283
B4_y: 0.200125
B0_x: 1.50197
B0_y: 0.730036
B1_x: 1.09778
B1_y: -0.285848
B2_x: 1.29582
B2_y: 0.195243
B3_x: 1.51337
B3_y: 0.0622596
B4_x: 1.00982
B4_y: 0.23544
B0_x: 1.53833
B0_y: 0.756552
B1_x: 1.1098
B1_y: -0.251912
B2_x: 1.30943
B2_y: 0.228571
B3_x: 1.52159
B3_y: 0.106503
B4_x: 1.02009
B4_y: 0.269945
B0_x: 1.57606
B0_y: 0.781086
B1_x: 1.12197
B1_y: -0.218032
B2_x: 1.31182
B2_y: 0.273508
B3_x: 1.5398
B3_y: 0.147654
B4_x: 1.03295
B4_y: 0.30357
B0_x: 1.61501
B0_y: 0.803617
B1_x: 1.13429
B1_y: -0.184207
B2_x: 1.31677
B2_y: 0.318234
B3_x: 1.55335
B3_y: 0.190565
B4_x: 1.04787
B4_y: 0.336332
B0_x: 1.65505
B0_y: 0.824147
B1_x: 1.14678
B1_y: -0.150443
B2_x: 1.32516
B2_y: 0.362446
B3_x: 1.56279
B3_y: 0.234564
B4_x: 1.06447
B4_y: 0.368278
B0_x: 1.69606
B0_y: 0.842677
B1_x: 1.15945
B1_y: -0.116746
B2_x: 1.33747
B2_y: 0.405729
B3_x: 1.56875
B3_y: 0.279167
B4_x: 1.08245
B4_y: 0.399466
B0_x: 1.73792
B0_y: 0.859207
B1_x: 1.17233
B1_y: -0.083128
B2_x: 1.3539
B2_y: 0.447624
B3_x: 1.57254
B3_y: 0.324008
B4_x: 1.1016
B4_y: 0.429949
B0_x: 1.78051
B0_y: 0.873732
B1_x: 1.18545
B1_y: -0.0496025
B2_x: 1.37442
B2_y: 0.48767
B3_x: 1.57423
B3_y: 0.368976
B4_x: 1.12177
B4_y: 0.459767
B0_x: 1.82373
B0_y: 0.886251
B1_x: 1.19883
B1_y: -0.0161833
B2_x: 1.38296
B2_y: 0.531852
B3_x: 1.58941
B3_y: 0.411338
B4_x: 1.14284
B4_y: 0.488957
B0_x: 1.86747
B0_y: 0.89682
B1_x: 1.21257
B1_y: 0.0170938
B2_x: 1.39435
B2_y: 0.575387
B3_x: 1.6178
B3_y: 0.446258
B4_x: 1.15646
B4_y: 0.522282
B0_x: 1.91164
B0_y: 0.905448
B1_x: 1.22669
B1_y: 0.0502072
B2_x: 1.41523
B2_y: 0.604713
B3_x: 1.64484
B3_y: 0.482221
B4_x: 1.16306
B4_y: 0.557672
B0_x: 1.95613
B0_y: 0.912153
B1_x: 1.24123
B1_y: 0.0831422
B2_x: 1.4393
B2_y: 0.631487
B3_x: 1.6705
B3_y: 0.519194
B4_x: 1.17515
B4_y: 0.59158
B0_x: 2.00088
B0_y: 0.916938
B1_x: 1.25624
B1_y: 0.115862
B2_x: 1.46629
B2_y: 0.655312
B3_x: 1.69479
B3_y: 0.55707
B4_x: 1.1923
B4_y: 0.623232
B0_x: 2.04571
B0_y: 0.920851
B1_x: 1.27179
B1_y: 0.148331
B2_x: 1.4912
B2_y: 0.692785
B3_x: 1.72975
B3_y: 0.585403
B4_x: 1.2139
B4_y: 0.652031
B0_x: 2.09061
B0_y: 0.923773
B1_x: 1.28791
B1_y: 0.180521
B2_x: 1.52035
B2_y: 0.727065
B3_x: 1.76413
B3_y: 0.614443
B4_x: 1.23925
B4_y: 0.677589

@whale-av said:

@ddw_music Yes.... buffer.
Maybe some DAWs have implemented a tempo message since then?

Tempo must be available, since plug-ins have been doing e.g. tempo-synced delays for at least a decade already.

(In fact, it is available via Camomile: [route tempo position].)

Anyway... I've been considering solutions, and I think I can do this.

1. Set some threshold close to the beat, but before the beat, say x.9 beats.
2. For the first tick past the threshold, get "time to next beat" = roundUp(pos) - pos = int(pos + 0.99999999) - pos.
3. [delay] by this many beats ([delay] and the tick-scheduler will have been fed "tempo x permin" messages all along).
4. Then issue the tick message to the scheduler, in terms of whole beats (where the time-slice duration is always 1.0).

At constant tempo, I'd expect this to be sub-ms accurate.

If the tempo is changing, especially a large, sudden change, then there might be some overlaps or gaps. But [delay] correctly handles mid-delay tempo changes, so I'd expect these to be extremely small, probably undetectable to the ear.

Half a beat at 60 bpm + half a beat at 120 bpm does indeed = 750 ms -- so the delay object is definitively updating tempo in the middle of a wait period.

I'll have to build it out and I don't have time right now, but I don't see an obvious downside.

hjh

@ddw_music said:

To work with the scheduler, I need to be able to anticipate the next tick time. The difference between successive beats (first number) appears to be consistently 0.04644012, and this seems to be proportional to tempo (160 bpm gets 0.061919212341).

Different machine, different DAW, I get half that (0.02322). So I guess this is a number of beats (because it increments by a larger amount at higher tempo = more beats per unit of time) and it must be updating once per audio callback, and the soundcards must be configured differently.

It's tricky: you can't just tick beats because you never get an exact whole beat (unlike abl_link~ which does provide a "step" output), and the beat interval between successive "playhead" ticks may change, and you won't detect that change until after you've already ticked the current one. So there will always be some sync inaccuracy AFAICS, probably minimal at constant tempo.

I guess nobody cares much about interoperability but I feel like I'm this close to a good way...

hjh

@ddw_music you could also use a combination of external and internal. keep track of the current beat #. If the next item in the queue is >= the beat # for the next tick then wait for the next tick. Otherwise, [delay] by the difference to the next beat value in the queue and then output the message (and increment the current beat #).

for example if you get 16th note (0.25 beat) ticks and are on beat # 0.5 with
elements in queue: 0.6 "something", 0.7 "something else", 0.8 "third thing":

-> check if beat value for next element ("something") >= (0.5 + 0.25) = 0.75 -> no
-> delay by (0.6 - 0.5) = 0.1 beats and then pop "something"
-> increment beat # to 0.6
-> check if beat value for next element ("something else") >= 0.75 again -> no
-> delay by (0.7 - 0.6) = 0.1 beats and then pop "something else"
-> increment beat # to 0.7
-> check if beat value for next element ("third thing") >= 0.75 -> yes
-> wait for next tick and then increment beat # to 0.75
-> check if beat value for that element ("third thing") >= 1 -> no
-> delay by (0.8 - 0.75) = 0.05 beats and then pop "third thing"
etc.