Hi,
with Firefox 88.0.1, Ubuntu 21.04 it loads and then Exception thrown, see JavaScript console:

unreachable code after return statement
EmscriptenExample.js:8289:4
unreachable code after return statement
EmscriptenExample.js:8413:4
undefined gameoflife.handmadeproductions.de:41:33
    printErr https://gameoflife.handmadeproductions.de/:41
    abort https://gameoflife.handmadeproductions.de/EmscriptenExample.js:859
    _abort https://gameoflife.handmadeproductions.de/EmscriptenExample.js:5284
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:124923
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:6889037
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:6889238
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:858086
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:766433
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:1044857
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:1488944
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:795390
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:193441
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:2719626
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:3663705
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:2876770
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:4943251
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:4467908
    _main https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9697
    callMain https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10601
    doRun https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10641
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10650
    (Asynchrone : setTimeout handler)
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10646
    runCaller https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10591
    removeRunDependency https://gameoflife.handmadeproductions.de/EmscriptenExample.js:848
    receiveInstance https://gameoflife.handmadeproductions.de/EmscriptenExample.js:920
    receiveInstantiatedSource https://gameoflife.handmadeproductions.de/EmscriptenExample.js:924
    (Asynchrone : promise callback)
    instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:940
    (Asynchrone : promise callback)
    instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:938
    createWasm https://gameoflife.handmadeproductions.de/EmscriptenExample.js:959
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9687
exception thrown: RuntimeError: abort(undefined). Build with -s ASSERTIONS=1 for more info.,abort@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:863:13
_abort@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:5284:5
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[497]:0x1e7fb
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[12138]:0x691e4d
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[12139]:0x691f16
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[2153]:0xd17e6
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[1931]:0xbb1e1
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[2449]:0xff179
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[3427]:0x16b830
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[1989]:0xc22fe
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[655]:0x2f3a1
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[6070]:0x297f8a
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[9295]:0x37e759
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[6933]:0x2be562
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[10347]:0x4b6d93
@https://gameoflife.handmadeproductions.de/EmscriptenExample.wasm:wasm-function[9921]:0x442cc4
Module._main@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9697:60
callMain@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10601:32
doRun@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10641:21
run/<@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10650:13
setTimeout handler*run@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10646:19
runCaller@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10591:9
removeRunDependency@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:848:13
receiveInstance@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:920:28
receiveInstantiatedSource@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:924:24
promise callback*instantiateAsync/<@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:940:31
promise callback*instantiateAsync@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:938:16
createWasm@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:959:5
@https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9687:11
gameoflife.handmadeproductions.de:41:33
    printErr https://gameoflife.handmadeproductions.de/:41
    callMain https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10614
    doRun https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10641
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10650
    (Asynchrone : setTimeout handler)
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10646
    runCaller https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10591
    removeRunDependency https://gameoflife.handmadeproductions.de/EmscriptenExample.js:848
    receiveInstance https://gameoflife.handmadeproductions.de/EmscriptenExample.js:920
    receiveInstantiatedSource https://gameoflife.handmadeproductions.de/EmscriptenExample.js:924
    (Asynchrone : promise callback)
    instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:940
    (Asynchrone : promise callback)
    instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:938
    createWasm https://gameoflife.handmadeproductions.de/EmscriptenExample.js:959
    <anonyme> https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9687
Uncaught RuntimeError: abort(undefined). Build with -s ASSERTIONS=1 for more info.
    abort https://gameoflife.handmadeproductions.de/EmscriptenExample.js:863
    _abort https://gameoflife.handmadeproductions.de/EmscriptenExample.js:5284
    _main https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9697
    callMain https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10601
    doRun https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10641
    run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10650
    setTimeout handler*run https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10646
    runCaller https://gameoflife.handmadeproductions.de/EmscriptenExample.js:10591
    removeRunDependency https://gameoflife.handmadeproductions.de/EmscriptenExample.js:848
    receiveInstance https://gameoflife.handmadeproductions.de/EmscriptenExample.js:920
    receiveInstantiatedSource https://gameoflife.handmadeproductions.de/EmscriptenExample.js:924
    promise callback*instantiateAsync/< https://gameoflife.handmadeproductions.de/EmscriptenExample.js:940
    promise callback*instantiateAsync https://gameoflife.handmadeproductions.de/EmscriptenExample.js:938
    createWasm https://gameoflife.handmadeproductions.de/EmscriptenExample.js:959
    <anonymous> https://gameoflife.handmadeproductions.de/EmscriptenExample.js:9687
EmscriptenExample.js:863:13

​

@ricky Finally! Someone else who's been studying this book!

Think of the x and y axis as the index of the output and input samples respectively. So if you're not delaying at all, then at output time 42 the delay line will output the input sample at time 42. That's what's expressed by the diagonal line from the origin. Everything above that line would be impossible without a crystal ball: for instance at output time 10 you can't output the input sample at time 50--that would be looking 40 time units into the future!

You're right about D being the maximum delay line length, but I think of it as the horizontal distance between those diagonal lines because that maximum length applies at all times. Everything below the diagonal from D would be impossible because the delay line can't store input samples more than D time units old.

So what you're subtracting are sample indexes, not the samples themselves. All that formula is saying is that at any given output time n, the delay line is outputting an earlier input sample, earlier by d[n]. Does any of this help?

Here's one more observation about this graph that might help clarify it: if one were graphing a fixed 10ms delay, it would be a line parallel to the origin diagonal, but 10ms to the right of it. With that, you can see that the dotted line starts at some delay amount, lengthens as output time progresses, then stops at some greater delay amount.

Hello everybody,
I would like to create a metronome that provides a beat time with phase, like the one provided by abl_link~ object, but in realm of messages.
The decimal values of the phase will be used by my sequencers to derive the rhythmic subdivisions (1/8, 1/16, 1/32, etc...), and in this way they can follow the realtime changes of the bpm.
I made a patch that use [metro], [cup] and [line], and it's working, but I noticed that at some bpm I don't have stable subdivisions, perceived by ear and also verified with a simple tap tempo.
Comparing my implementation to another one that uses [line ~], I noticed that the one with [line ~] is more precise, probably because [line~] provides more decimals than [line], and perhaps this is what causes the subdivisions based on [line] to be less precise.
What do you think? Do you have any advice on how I could implement it to have stable subdivisions?
I would like to avoid solutions in the "audio realm" like [line ~], because they would create other problems of sync with other pieces of my project, which works exclusively with messages.

Here is the patch I made (both [line] and [line~] included):
metro_phase.pd

@Nif.40 The CMD window will not normally close when it has completed its commands...... you need to give it an exit command to close it...... but you cannot do that.... see below.
It then returns focus to your patch.

You can give it a command it cannot complete..... like start with no executable path given.....
start echo my-message
You can open it and keep it open.....
CMD /K
You can open it and pause it but it will not then even get to the command prompt......
PAUSE
You can get focus back to your patch by it sending a vis 1 message to itself afterwards......
; pd-mypatch.pd vis 1

But you can only send one line with no carriage return into the command window because ; is interpreted in Pd as the start of an internal message to Pd.
So I doubt that any of that is useful.
I am almost certain that all you can do with [system] is run a single line batch file.
I am almost certain that you cannot make the cmd window behave like an open terminal receiving messages from Pd.

So this message (on my system) sent into [system] will open midiox.......
"C:/Program Files (x86)/MIDIOX/midiox.exe"
It has to be in quote marks because there are spaces in the directory path...... the quote marks keep it all together...... otherwise it is seen as separate messages and only C:/Program is actually executed....... in fact not executed because it is meaningless...
It is certain that the message you are sending into [system] is simply incorrect....... and that is why nothing happens.
The message you send has to work as it would in a normal batch file.
So for help with your message look around for help with batch files.
David.

It is exactly the single pixel lines that I find objectionable.

The changing thickness seems to be an approach to the problem where the stairsteps would be of a different length, e.g.

*
 *
  *
   *
    **
      *
       *
        *
         **
           *

Frankly they both look gross to me. I think you're trying to say that the rendering in my screenshots is wrong and the above demonstration of a 1.2:1 pixel slant would be right -- but I dislike both of them.

I'm willing to consider that if I saw smoothed lines throughout Pd, I might feel like it's too much fuzz -- but I doubt it. When I tried Purr Data, my first thought was "ah, finally, lines that don't make my eyes hurt." (But then I had to abandon Purr Data because I need Gem for a class, and Gem isn't supported in Purr Data for Mac, so I couldn't use it in the school's Mac-based media classroom... so, back to vanilla.)

In a perfect world, I could choose smoothed lines and oid could choose single pixel lines, but...

seb-harmonik said:

on windows it uses gdi, which does not support antialiasing and on linux it uses xlib, which also does not support antialiasing

That's unfortunate. Kind of underscores the point about being out of date -- that will continue as long as the buck gets passed (Pd: "Line drawing is Tk's problem"; Tk: "Line drawing is xlib's problem" and xlib will have some reason not to catch up with modern line drawing). It's a shame that an important part of the computer music ecosystem get held back by dependencies that aren't catching up.

hjh

I have to admit that I forgot to get the Mac screenshot yesterday (smh).

@oid said:

free of the weird artifacts which I assumed were caused by a post screen grab resize, but could have been caused by the screen grabber itself. Lines should not be changing thickness like that, most noticed on the line between [moses] and the number box, they should be 1 pixel wide but it alternates between 1 and 2 pixels in width.

That issue is not caused by the screen grabber. It's the normal appearance of Pd for ages. See the 2nd "Modulation index" --> [*~]. (This is a png -- there are no jpg compression artifacts. This is how it really looks on my screen, in the Pd window.)

"Lines should not be changing thickness like that" -- agreed, but by that standard, then Pd's line rendering is sub-par. Lines in Pd have always been changing thickness, for as long as I've ever used it.

It's a (more-or-less) solved problem in the graphics world. FWIW here is angled-line drawing in SuperCollider (using Qt). Here, I've chosen an angle that will be maximally fuzzy. It's not great exactly but, in my opinion, less distracting than Pd's current display.

whale-av quotes seb-harmonik: "Tk/Tcl has solutions in the pipeline" ... erm... but... again, it's a solved problem. Tcl/Tk hasn't caught up with the rest of the world.

@whale-av said:

Pd I use as a tool to get things done and how it looks is unimportant except for keeping patches clean and readable.

I do understand, but I don't quite agree that appearance is completely unimportant.

For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.

I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.

I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk). But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.

hjh

@yannseznec there is a limit in precision for any finite numerical representation. However, for floating point that becomes more complicated to calculate. The relevant code is

x->x_biginc = (x->x_target - x->x_value)/(t_float)nticks;
x->x_inc = x->x_1overn * x->x_biginc;

and in the dsp function:

x->x_1overn = 1./sp[0]->s_n;

so the inc will be (target value - current value)/(total time in samples). Time in samples will be rounded to the block size. I believe whether or not this number will increment the line~ depends on how big or small the current value of the line~ is. (again, it's complicated since it's floating point).
for instance if the current value of line~ is 1 then inc would have to be less than 2^-24 to not be able to increment I think. this would correspond to going from 1 to 2 over 16777216 samples, or ~6 minutes 20 seconds @ 44100 samplerate. (so you couldn't go from 1 to 2 any slower than that and have it represent the correct values within the block). Every time the value of line~ doubles so does the smallest representable increment.
however, line~ also uses the biginc variable, which means that after every block it will be able to update using a bigger increment. This means that line~ will still be able to increment up to blocksize times more than that calculation ^ after every block, though values inside every block would be the same. (so ~6 hours 46 minutes @ blocksize 64 according the above calculation I think)

if going from 0 to 1 all of those values would be doubled (it could represent increments corresponding to twice that time, bounded by the lowest representable increment that corresponds to going from 0.5 to 1)

there are other considerations of precision as well. If the increment can only be represented with a certain number of binary digits when added to the current value then there will be round-off errors in the values generated. (but if you need values of that precision you would have round-off errors somewhere else anyways probably)

another numerical bound on the use of line~ is the use of an int to represent ticksleft. If we assume this is a 32-bit signed integer then there can only be 2,147,483,647 blocks, which is ~36 days @ 44100 samplerate and a blocksize of 64. (this would be longer than whatever limitation the floating-point would impose tho I think)

this is all assuming that the size pd uses for samples and floats are 32-bit floating point. If pd is compiled to use 64-bit doubles instead then all of those values would be 2^29 times longer

edit: actually, looking at the code vline~ does use doubles for everything, so if you need really long ramps you should have no problem if you use vline~ instead of line~, even in normal non-double pd. It would take a time longer than 6,472 years for a vline~ going from 1 to 2 to stop being able to increment within a block of 64 samples @ 44.1k. (and a time of 414216 years to stop incrementing at all across blocks)
In the case of vline~ the bounding factor of precision might be in the representation of time actually since it doesn't use ticksleft
edit 2: it couldn't represent incrementing ~1.45 ms which is the time for a block of 64 @ 44100 samples if the current time were ~ 2^53 ms, which would be 9007199254740992, or 285,421 years before stopping to work completely.

long story short: you should be able to use vline~ (but not line~) for ramps of at least a few years long (depending on the range of its values) before it stops incrementing within a block. For the specific case of going from 0 to 1 @ 44.1k, you should be able to run a vline~ for ~129,000 years before it stops incrementing within a block (though it would still increment between blocks)

Hello folks,

I have been struggling for the last several days trying to get any version of Puredata to work correctly on Chromebook Crostini. It almost works. It runs and I get sound but it is extremely scratchy and broken up.

Firstly, I know that audio can work because csound 6.12 works well with perfect sound. No hiccups at all.

I am running 83.xxxxx.77 official version of chromeos on an acer 14" Chromebook. I have tried many things to try to get some version of Puredata to work. I have used apt-get to install pd-version 0.49.x. I have downloaded and built from source pd versions 0.50.2 and 0.51 (brand-new). Every version runs and makes a similar complaint both on the command line and in the running program (see below):

"priority X scheduling failed; running at normal priority" - where X is 94, 92, 8 or 6.

I have tried multiple command line switches and setup parameters all with the same results. Additionally, as you can see from the screencapture below, once DSP is turned on the helpful 'Audio I/O error' message is displayed. I have researched and tried many things including adding the audio group and my name to '/etc/security/limits.conf' with the same result. Also, I have run pd without realtime scheduling: 'pd -nrt' with the same scratchy sound results.
I would be extremely grateful to anyone who could help me solve this problem or point me in the right direction. Perhaps I am missing something simple and/or obvious. Thank you in Advance!

Hello everyone, I'm currently working on somekind of "fork" of a patch I found(it's a groovebox patch coded by Martin Birkmann). It consume quite a lot of CPU, on my current Laptop equiped with an Intel® Core™ i3-6006U CPU, it ran up 50% on the first core. Since i want to be able to run it on a Raspberry Pi 3, running the patch at about 1 ghz on a single core is just not possible. Then I looked up how I could optimizes the use of the cpu, I tried to use some puredata command flag, tried to simplify and hide most of the GUI and even tried to split up the patch with subprocesses with pd~.

First flags, changes of priority, realtime ect... doesn't do anything for the use of CPU. Secondly hiding some GUI maybe help to grab 1% or 2% of CPU. Finaly, I had great hope that pd~ would allow to spread the CPU all across the proccessor allowing me to run it on the RPI 3, but no it's strange the mother patch of the subprocesses is running at 18-20% of CPU use(about 60% on a single core) consuming more than the initial patch that runs at 10-12% of CPU use. And when I'm running the pd subprocesses they also grasp a load of cpu use, They consume about as much as the mother patch, which is quite the opposite of what I wanted...

So is it normal that the use of pd~ just increases the need of CPU time for pd ? Is there another way to split the audio processing in different pd instances s the calculation is shared by different cores ? Is there some things I could improve in the audio processing section that could help lowering the use of CPU ?

Then I have another problem whenever I wanted to activate the dsp when I was on my RPI pure data craches. Is there someone here that knows why ? What command should I use to use the dsp without crash on a rpi ?

If you don't see any solution to my problem then you maybe can help me in an another way? Since my problem is mainly optimisation, if you have some recommandation to gave about some pure data open source groovebox patch that run well on low spec system it would be great.

Hello all! I'm an experienced software engineer but a pd newbie.

For the patch I'm working on, I have the settings being output on several lines which each represent parameters for conceptually distinct parts of the patch. It's important to me to keep the output format with these sections on separate lines for purposes of future development / my sanity / general hygiene, etc.

However, I cannot figure out how to read these lines separately, in order. I'm sure I'm missing something basic, but after hours of trying to puzzle through the documentation and the net in general, I haven't found one which gives me the pieces I seem to need. I don't need anything fancy, just something which allows me to separately dispatch each specific line to code that will parse it and send the proper messages to set up the patch accordingly. There is a known number of lines, so no fancy logic is warranted, just: first line, do this, second line, do this other thing.... up to the sixth line.

If anyone can point me to an example of something like this, I would be quite grateful.