@mathsound said:

is actively being developed

Not really "actively" I'd say... the development pace really slowed down in the last couple of years with less releases. Pd-L2ork seems much more active. About 'multiple cord connection', Vanilla has the same and actually more "intelligent patching" options.

I check in PD Vanilla 0.55-2, and adc~ works (on my new M4 Mac),
so it's definitely a Purr Data issue (with newer Macs / OS) - maybe
as it's based on PD 0.48.

0.55 down to 0.48 is basically 7 years of development behind

So actually you did provide the solution!

yeah, I had a hunch Pd-L2ork is performing and doing better

Now I wonder why Purr Data exists alongside L2Ork, as to me they look and act the same?

well, they are similar, but they're not the same, they are independently developed and not fully compatible to each other. It happens because this is open source and people can fork and work on their own branch. This has advantages and disadvantages depending on the project. For something like Pd, where the community is relatively small, I think it's bad, as it divides the community, specially if it involves incompatibilities, which is the case with Purr/L2ork, which are not only incompatible to each other, but with Vanilla, specially that. And also quite outdated, though they are finally catching up. Seems like the last Pd-L2ork version made the jump from 0.48 to 0.55! Updating libraries like Cyclone is next in the to do list, as they have a version from 20 years ago and don't have the developments from the newer phase that is almost a decade long now.

I like to point this because I think many people don't seem to grasp the differences and caveats, and maybe they don't even mind them but it's worth noting and knowing!

Even if you finally have it synced to the latest updates in Vanilla and the external libraries they carry, there are also the incompatibilities issue that I find most problematic, as you can't run the same patches on other forks (not only Vanilla), and some external GUIs weren't ported yet and I wonder if they ever will (there aren't that many of them anyway). So full Pd-Extended compatibility is still better guaranteed with Vanilla, this is a fact.

What maybe people don't really also get is that there are things beyond Pd-Extended, and new things and new external libraries that came to be after the demise of Extended over a decade ago... with pd-l2ork/purr data you are stuck with the limited set they offer and the incompatibilities are so big that you can't even run externals made for Vanilla in them. So you're missing out on some stuff...

If you can't stand Vanilla and really like GUI enhancements you can look into PlugData, which comes with some external libraires but also allows you to install libraries in the standalone app. There's also the same issue with some GUI objects in external libraries not being ported, but there aren't that many and they do offer lots that are ported anyway.

@porres But this is way cooler and provides a great deal to learn from

Oh, I missed this. Well, sorry then for suggesting an external that does it then? I see now it's not cool and doesn't provide a way for people to learn, maybe I shouldn't have suggested, is that it? Sorry for the sarcasm, but I don't know how to respond to this and I'm just either very surprised or I don't get where this is coming from. Should I should never ever suggest any external, as some random people might say they don't want externals? I'm really trying to understand where this is coming from, please help me understand what you mean...

Vanilla might be more work and less efficient than an external but the efficiency is not that big of a deal these days and that work is rewarded with better understanding of pd and gives the ability to do far more than externals generally allow.

You can't play soundfonts in Vanilla wihtout an external, maybe you missed that part? Note that @Balwyn suggests people to use "RGC-Audio" plugin loaded via the [vstplugin~] eternal.

Anyway, not being sarcastic now, but if I ever suggest other externals in this forum and people, for whatever reason, don't like using externals and want to just be fully Vanilla, I guess it makes sense to keep it to oneself as this is not about this person... you know? If people don't like externals, don't use them and don't criticize people that offer externals. Maybe others in this forum kinda like using externals right? And anyway, if anyone wants use soundfont in Pd, this person definitely need externals!

Let's be honest, if you are using free/open source software that you do not support and that you do not collaborate to in any way and that you do not follow closely to be aware that some features aren't actually supported, you're not really "screwed" if you use such features... you also have absolutely no right to get "pissed" and rage with hate like you did about this on facebook.

I find your attitude quite egocentric and offensive to Timothy and everyone involved in the great development of PlugData, they deserve much better respect and support.

You've been quite disrespectfully on facebook to the Pd community in general with your mentality and rage outburst for being "pissed" about the "discontinuity" of Ofelia (which wasn't discontinued as it was never oficial) and then saying you have abandoned PlugData now for good and are now using MAX4LIVE instead... you have managed your tone about it all here, maybe cause you don't want to get banned here as well, but this information is also found on your personal website and you have even mentioned how you are "rightly pissed" and attacked me there!

You have to be really politically ignorant to treat a comercial software like MAX and Pure Data as equals and rage about a free and open source project not offering what you want, as if you were a "customer" not getting you what you need, for free, when you're not engaged in that community at all. Why don't you try and fix and make Ofelia part of PlugData... why don't you support it financially since you are willing to pay for commercial software instead?

Well, I guess don't do that, go ahead and leave the community, if you do not outburst in rage again and just get banned as well. I guess Open source projects are not for spoiled and self centered people who just want to take and not give anything, and then badmouth the project when it is not "sufficient".

And for the record, [pdlua] has been officially supported and part of PlugData for over a year now and won't ever be discontinued. It's also getting awesome new features like graphics support and inline scripting (as Ofelia offered). But [pdlua] will now just be integrated into ELSE and maybe called something "else".

cheers

@manuels I was not prev aware of these other kinds of white noise but they are all smooth and so don't produce the kind of texture I want. To give you a sense of what I'm looking for, here is the sound of a drip into an empty tin can: tinCanDrip1.wav. Convolved with binary white noise, you get this: tin can conv binary noise.wav. Now here is my nasty-sounding whitening of bubbling water and it's convolution with the tin can: whitened bubbling.wav & tin can conv whitened bubbling.wav. See how the result sounds a little like a small stone being rolled around the bottom of the can?

Also, that's interesting about [noise~] in overlapped windows, I'll go back and modify my version of that patch to see if the lo-fi mp3 quality goes away.

@whale-av "randomly modulated in its amplitude"--yes, that's what I tried with the 64 band 1/5 oct graphic. It's not bad, but it's not natural sounding either. Could be useful anyway, depending on the effect you want.

@ddw_music My problem isn't the convolution (I'm using REAPER's ReaVerb for that), I'm just wondering how to make the kind of IR that produces the effect I want. Your rifft strategy is what I speculated about in my original post and what I first tried using [array random] to generate freq domain moduli with a similar distribution as [noise~]. FYI Pd's real inverse FFT automatically fills in the complex conjugates for the bins above Nyquist, so you don't have to write them--leaving them as all 0 is fine. Also note that your [lop~] is filtering the change between successive bin moduli in a single window, not the change of each bin from window to window. I'm speculating that the latter (maybe using asymmetric slewing rather than low pass filtering) would make frequency peaks hang around longer (and hence more audible) whereas I'm not sure what the former does. That said I think the strategy of modifying natural sound is paying off faster than these more technical methods.

@jameslo of course, 'comb filter theory'' is just math and that can account for negative coefficients (and even imaginary/complex ones :->)
if you use a negative coefficient then it will be an octave down from where it would be if positive, because the original period cancels exactly, but at an octave down it is constructive.
the wikipedia article seems like it might have some insight about negative coefficients (essentially the 'teeth' are shifted by an octave down)
so it is an octave down, but only contains odd harmonics of that fundamental (the negative part will catch the 2nd half of a sine period in the middle of the 'transition', and constructively interfere with the 1st half of the 1st period if the harmonic is odd but if even it will be destructive)
https://en.wikipedia.org/wiki/Comb_filter

when we take the delay down to 1 sample I believe you get a highpass instead of a lowpass, because now an 'octave down' from the samplerate (or 0) is nyquist

@Muology Generally it is better to stick a subpatch in the abstraction and do your dynamic patching in there so you can exploit the [clear( msg, method is about the same, don't need to keep track of object numbers as closely but sometimes it is the only way. iemguts is worth exploring if you are getting into dynamic patching.

dyn-abs.pd
dyn-abs-test.pd

Edit: Forgot the patch message question. PD messages send interface commands like save or open, patch messages are the dynamic patching messages, these are better found from opening patch files in a text editor or you can use my look abstraction, with it you can get you exact messages needed for any give dynamic patching, just patch together what you want to dynamically create in an empty patch or subpatch, create the [look] abstraction then select everything but it and control click the bang, your messages and their connects will print to the log for you to copy. It is important that [look] is created last other wise it will screw up your connect messages but it does number the objects for you so not difficult to adjust them as needed so you can even skip using an empty patch/subpatch without much fuss.

Hi,

I am trying to get ofelia to run on a couple of rpi. Right now I am trying a rpi 3B+ running https://blokas.io/patchbox-os/

I run ofeila with the ofelia-fast-prototyping abs on my mac successfully.

Following install instructions here https://github.com/cuinjune/Ofelia
after running
sudo ./install_dependencies.sh
it ends like this:

detected Raspberry Pi
installing gstreamer omx
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
gstreamer1.0-omx is already the newest version (1.0.0.1-0+rpi12+jessiepmg).
The following package was automatically installed and is no longer required:
  raspinfo
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Updating ofxOpenCV to use openCV4
sed: can't read /home/patch/Documents/Pd/externals/addons/ofxOpenCv/addon_config.mk: No such file or directory
sed: can't read /home/patch/Documents/Pd/externals/addons/ofxOpenCv/addon_config.mk: No such file or directory

When running the example patches in Pd I get this in PD console:

opened alsa MIDI client 130 in:1 out:1
JACK: cannot connect input ports system:midi_capture_1 -> pure_data:input_2
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia d $0-of
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia f ;
 ofBackground(20) ;
 ofSetSmoothLighting(true) ;
 ofSetSphereResolution(24) ;
 local width , height = ofGetWidth() * 0.12 , ofGetHeight() * 0.12 ;
 sphere = ofSpherePrimitive() ;
 sphere:setRadius(width) ;
 icoSphere = ofIcoSpherePrimitive() ;
 icoSphere:setRadius(width) ;
 plane = ofPlanePrimitive() ;
 plane:set(width * 1.5 , height * 1.5) ;
 cylinder = ofCylinderPrimitive() ;
 cylinder:set(width * 0.7 , height * 2.2) ;
 cone = ofConePrimitive() ;
 cone:set(width * 0.75 , height * 2.2) ;
 box = ofBoxPrimitive() ;
 box:set(width * 1.25) ;
 local screenWidth , screenHeight = ofGetWidth() , ofGetHeight() ;
 plane:setPosition(screenWidth * 0.2 , screenHeight * 0.25 , 0) ;
 box:setPosition(screenWidth * 0.5 , screenHeight * 0.25 , 0) ;
 sphere:setPosition(screenWidth * 0.8 , screenHeight * 0.25 , 0) ;
 icoSphere:setPosition(screenWidth * 0.2 , screenHeight * 0.75 , 0) ;
 cylinder:setPosition(screenWidth * 0.5 , screenHeight * 0.75 , 0) ;
 cone:setPosition(screenWidth * 0.8 , screenHeight * 0.75 , 0) ;
 pointLight = ofLight() ;
 pointLight:setPointLight() ;
 pointLight:setDiffuseColor(ofFloatColor(0.85 , 0.85 , 0.55)) ;
 pointLight:setSpecularColor(ofFloatColor(1 , 1 , 1)) ;
 pointLight2 = ofLight() ;
 pointLight2:setPointLight() ;
 pointLight2:setDiffuseColor(ofFloatColor(238 / 255 , 57 / 255 , 135 / 255)) ;
 pointLight2:setSpecularColor(ofFloatColor(0.8 , 0.8 , 0.9)) ;
 pointLight3 = ofLight() ;
 pointLight3:setPointLight() ;
 pointLight3:setDiffuseColor(ofFloatColor(19 / 255 , 94 / 255 , 77 / 255)) ;
 pointLight3:setSpecularColor(ofFloatColor(18 / 255 , 150 / 255 , 135 / 255)) ;
 material = ofMaterial() ;
 material:setShininess(120) ;
 material:setSpecularColor(ofFloatColor(1 , 1 , 1)) ;
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia f ;
 pointLight = nil ;
 pointLight2 = nil ;
 pointLight3 = nil ;
 collectgarbage() ;
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia f ;
 local width , height , time = ofGetWidth() , ofGetHeight() , ofGetElapsedTimef() ;
 pointLight:setPosition((width * 0.5) + math.cos(time * 0.5) * (width * 0.3) , height / 2 , 500) ;
 pointLight2:setPosition((width * 0.5) + math.cos(time * 0.15) * (width * 0.3) , height * 0.5 + math.sin(time * 0.7) * height , -300) ;
 pointLight3:setPosition(math.cos(time * 1.5) * width * 0.5 , math.sin(time * 1.5) * width * 0.5 , math.cos(time * 0.2) * width) ;
... couldn't create
/home/patch/Documents/Pd/externals/ofelia/ofelia.l_arm: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
 ofelia f ;
 local spinX = math.sin(ofGetElapsedTimef() * 0.35) ;
 local spinY = math.cos(ofGetElapsedTimef() * 0.075) ;
 ofEnableDepthTest() ;
 ofEnableLighting() ;
 pointLight:enable() ;
 pointLight2:enable() ;
 pointLight3:enable() ;
 material:beginMaterial() ;
 plane:rotateDeg(spinX , 1 , 0 , 0) ;
 plane:rotateDeg(spinY , 0 , 1 , 0) ;
 plane:draw() ;
 box:rotateDeg(spinX , 1 , 0 , 0) ;
 box:rotateDeg(spinY , 0 , 1 , 0) ;
 box:draw() ;
 sphere:rotateDeg(spinX , 1 , 0 , 0) ;
 sphere:rotateDeg(spinY , 0 , 1 , 0) ;
 sphere:draw() ;
 icoSphere:rotateDeg(spinX , 1 , 0 , 0) ;
 icoSphere:rotateDeg(spinY , 0 , 1 , 0) ;
 icoSphere:draw() ;
 cylinder:rotateDeg(spinX , 1 , 0 , 0) ;
 cylinder:rotateDeg(spinY , 0 , 1 , 0) ;
 cylinder:draw() ;
 cone:rotateDeg(spinX , 1 , 0 , 0) ;
 cone:rotateDeg(spinY , 0 , 1 , 0) ;
 cone:draw() ;
 material:endMaterial() ;
 ofDisableLighting() ;
 ofDisableDepthTest() ;
... couldn't create

Thankful for help!

@Alan-Angel said:

1. I don't plan on play two left hand notes, I just want to play fast galloping basslines like dun du-du dun du-du dun du-du dun and it'seasier to do with one hand and play the notes with the other, like a real bass.

OK, so, hold a pitch with the right hand and play fast notes with the left -- rhythm and articulation under control of the left hand. So that removes some cases.

However... user-interaction data are always dirty. You say "I don't plan on..." but in practice, when you're playing, the actual MIDI messages coming in will not always conform to the ideal. So if your patch is like "it works as long as I never X"... trust me... sometimes X will happen... the patch needs to be able to handle it.

E.g.:

I think the following two scenarios are guaranteed to happen sometimes:

1. You hit the right and left hand notes "at the same time" but the left-hand note arrives first. If the logic here is "nothing is currently held in the right hand, so, do nothing," then the first note will become a rest. So there should probably be some logic such as "if the right-hand note arrives within a certain time window after the left-hand note (like 20-30 ms or less), then play it once both are received."

2. While rolling the fingers over G-A-B in the example, some of them overlap. If you're using left-hand note-off to release notes, and you don't account for overlaps, then some notes will be cut off prematurely.

For problem 2, assuming mono, you would release a playing note if the note-off matches the last note to be played:

1. note on 43
2. note on 45 -- then, quickly, note-off 43
3. note on 47 -- then, quickly, note-off 45
4. note off 47

At 2, note-off 43 should not cut the note off because it isn't the currently active trigger note number (but, since note-on 45 is rearticulating, then it will have to generate a note-off before the next repeating note-on!). But, at 4, note-off 47 should cut off the note.

I'm not sure I have time myself to build all of this, but maybe I can do some pieces of it and post them later.

hjh

@whale-av said:

@Alan-Angel You could be right about the order of operations......... https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum
You need to store the right hand note so that it can be played later by hitting the left key.
I have broken it down into (I hope) an understandable work flow for a mono player....... this.pd

So that even if it doesn't work you should be able to understand the order of operations and fix the problems...
[pack f f] receives the velocity of high notes.... but that value is replaced by the velocity of the low note just before the low note triggers the playing of the high note.

If you want to do this polyphonically you will need to use the [poly] object and to use the finished mono patch as an abstraction within a master patch containing [poly]...... probably using [clone].
That's slightly more complex.... but you will get there.....
David.

Thanks for your help. the low velocity isn't registering, I'll try to figure out why not but I get the logic.

@kosuke16 said:

Whale is right, my bad. I tried it only with the numbers, no audio so while the numbers where good, the timing wasn’t. Note message not being continuous, you have to repack it so it is send at the same time than the velocity to make a coherent list of two values for noteout.

Thanks for your help so far!

@ddw_music said:

My question about this:

• Right hand first, then left hand: Note should be produced upon the left-hand note on.

  • What if one right-hand note is pressed, and two or three left-hand keys? Multiple notes, or only the first? (Polyphony, I suppose, would have to be right-left, right-left, not the same as right-left-left.)

• Left hand first, then right hand: Should it play the note upon receipt of the right hand note-on, with the left-hand velocity? Or not play anything? Or something else?

  • And, if it should sound, what about left-right-right? Portamento? Ignore the second?

Because a full solution will be different depending on the answer to these questions. These need to be thought through anyway because you can't guarantee correct input -- the logic needs to handle sequences that are not ideal, too.

hjh

1. I don't plan on play two left hand notes, I just want to play fast galloping basslines like dun du-du dun du-du dun du-du dun and it'seasier to do with one hand and play the notes with the other, like a real bass.

2. Not sure about this one, I guess I'll know the more I play how I want it to work. Maybe default it to a low E like on a real bass for fun?

3. Agree, for now I just want some basic functionality to even see if the instruments I use can handle fast notes in the first place.

@jameslo said:

if we stipulate that people can't hear the relative phases of harmonics, then shouldn't there be some arrangement of a given tone's harmonic's phases such that the DC component is maximal

This actually isn't true. The integral of a sine wave is always 0. The sum of the integrals of multiple sinusoidal components, then, must also be zero.

If you have extremely low frequency components, like 1/10 Hz, then at any given moment, that component's contribution in the short term may resemble DC and may be just as harmful to speakers as DC. But this isn't a harmonic component of a tone whose fundamental is audible, so it's not properly part of the "tone" that you mentioned.

True DC must have frequency = 0, which isn't a harmonic of anything (but which is necessary in Fourier analysis to account for an average offset away from the zero line).

That's interesting about the warble tones as beating, like an amplitude modulation artefact. EDIT: I'm having trouble, actually, finding a consistent definition of "warble tones." Some sources refer to frequency modulation, while others say it's amplitude modulation consistent with oid's post. That's not making it easier to evaluate the claims.

hjh