Limiting amplitude on an LFO
Hello,
In the context of a MIDI to CV converter, I am trying to limit independantly the lower and upper points of a waveform. The reason for that is that when I play high pitches, the LFO added to the keyboard pitch makes the final value go over 1, creating a kind of high pitched plateau that I would like to avoid. On the other hand, I would like to allow the lower part of the LFO wave to continue its course, so the waveform would be asymetrical in a way, for example going from -1 to +0.2. I achieved this with different vline~ objects, by setting two $ for posMax and negMax and it works fine. Here is the patch.
Now my issue with hat solution is that it doesn't play smoothly when adjusting the LFO rate, I suppose due to the fact that the different vline~ have to update while playing and they don't like it. Anyway, I am back to square one because playability and modulation possibility for the LFO speed is a must.
My math knowledge is not enough to figure out what kind of equation I should write to mathematically create the waveforms. Or maybe there is another way ? I went through the oscillators creation tutorial by Alexandro Drymonitis but couldn't find a way to adapt his patches so I could control the positive and negative parts of the waveforme independantly.
If anyone could put me in the right direction, it would be great.
Thank you.
saving a sample with a temp-filename so another app can run it?
@esaruoho Live is either working from its own copy of plom.wav stored elsewhere or just assuming the file has not changed for some reason. For the former finding where Live stores its copy and deleting it with [command] before opening the new one might be enough, for the latter perhaps opening a really short audiofile (like 1 sample long) before opening plom.wav will give Live the kick in the ass it need to actually check plom.wav's attributes and see if it is the same file. For both, deleting plom.wav before writing to insure it is a new file could work, Live could be going by file creation time instead of modification time because it assumes you are doing all your editing in Live so modification times will not change, this assumes OSX has creation time (it did years ago) for files but it is simple enough to test, suppose you can also trying running touch
on plom.wav before the open command.
No need to try combinations of these methods, I doubt combining would work, they either work or they do not. But they should be a bit more efficient than reworking names which could be of use for you since you sound like you are already running out of space between blocks.
error message when using usb audio interface on pi with pd
Bad luck indeed. many hours of frustration I had now..
In my pd patch there is no live performance rather audio track playing based on people interacting with some sensors. In that case is better if I set delay higher than 20? maybe 100?
edit: I re-read your last post. What you are actually saying that if I don't have live use in the patch it is not matter if my delay is 5ms or 300ms(as a example)? it will not help improving pd performance (in term of cpu) ?
What actually help my patch to perform as it should is the fact I have change the block size from 64 to 512?
Stack overflow when trying to increase the size of a functioning "Game of Life"-patch
@SignalsInNoise Here are some other implementations of the Game of Life:
With data structures:
- https://forum.pdpatchrepo.info/topic/10916/conway-s-game-of-life-implementation-with-data-structures
With ofelia:
- https://forum.pdpatchrepo.info/topic/11826/conways-game-of-life-made-with-ofelia
- https://forum.pdpatchrepo.info/topic/13155/game-of-life-patch-v2-ofelia-v4-offbo-issue-with-standalone-app
- https://forum.pdpatchrepo.info/topic/13181/game-of-life-new-attempt
- https://forum.pdpatchrepo.info/topic/13248/3d-game-of-life
With Ofelia / Emscripten (working in the browser):
Demonstration of the 5 Basic Synthesizer Modulation Types
UPDATE: 2023-01-11:
I just noticed the zip was missing the needed [sc] abstraction to play the tester. Have updated the zip below to include it. Please, accept my apologies for the deficiency. -PTS-LTM, s
the5basicmodulation-synth-types-2(w-missing-sc).zip
(no other changes)
Before I built Jass~(Gemini) I first had to spend a lot of time gathering together all the information I could about all the basic synth types.
This patch consolidates all 5 of the basic types (additive, frequency, phase, pulse, and amplitude) under one heading so that they may be more quickly, easily, and readily comprehended.
It includes selectors for the carrier and modulator wave types, as well as, the two basic controls for each type, and an array so you can both see and hear how those basic types look, feel, and sound.
It's also just sort of cool to listen to.
I hope it may make it easier for you to digest the (what may initially seem complex ideas) more readily and conveniently.
Note: the floss-manuals have a lot to say about it, but leave off some stuff. And the audio-examples -help files are spread out across a lot of space and leave off the viable ranges for each control/parameter.
Good luck! Happy PD-ing. Stay healthy and
Peace through Music and Love through sharing.
p.s. if you find something that is "wrong" about the patches, in terms of how that type of mod is suppose to work, please, let me know, as I did have to guess about a lot of stuff and would love to learn.
Organelle
I have one and I have to say that this is one of the best things that happened to puredata..
initially, just by looking at pictures of it and hearing sounds I wasn't attracted to it at all.. Also, knowing how a raspi 1ghz performs (like shit..) I was imagining that the device was too pricey and uncapable of doing something complex with audio..
Then a colleague bought one and When I tested my hardcore patches, I was very surprised to see that they did perform super good and even with very low audio latency.. Also. I have been through the pain of running pd headless in raspi, protecting the sd against writting, enabling usb patch storage, interfacing with display, latency optimization, etc etc.. and I have to say that they did a brilliant job..
This thing performs super good... it's reliable and easy, definitely, it could be cheaper, it could have another design, etc etc.. But if you judge it for what it does, it's the best thing out there, IMHO.....
Also, While I wouldn't pay the sticker price for it. A second hand unit for 3xx Eur / Dollar, (Even the old model) I think is a bargan.. Raspi + additional needed shit gets you close to that number but this would save you lots of headaches...(And probably still performs better)
I did run my patch in a raspi 3 + pisound and the performance and stability were worst (I don't know if is the raspi hardware or raspbian) So I also like to stick with the old Arch / Solid run combo (New units use rp3cm +raspian)
I will release soon a light version of s3rquencer as open source:
http://servando.teks.no/?patches
greetings
S
Paradigms useful for teaching Pd
@ingox Ha, I guess this highlights the number 0 paradigm for Pd-- always measure first!
It looks to me like message-passing overhead dwarfs the time it takes to copy a list once into [list store]
. That single full list-copy operation (a for loop if you look in the source) is still significant-- about 10% of total computation time when testing with a list of 100,000 elements.
However, if you remove all message-passing overhead and just code up [list drip]
as a core class, you consistently get an order of magnitude better performance.
So we have:
- original list-drip: slow, but I can't find the code for it. But I hope it was just copying a list once before iteration, and not on every pass.
- matju's insane recursive non-copy list-drip: faster than the original implementation
list store]
implementation of[list-drip]
: looks to be consistently 3 times faster than number 2 above, lending credence to the theory that message-passing overhead is the significant factor in performance. (Well, as long as you aren't copying the entire list on every pass...)- Add core class
[list drip]
to x_list.c and use a for loop to output each element from the incoming vector of atoms without copying anything. I quickly coded this up and saw a consistent order of magnitude performance improvement over the[list store]
implementation. (Didn't test with gpointers, which will probably slow down every single implementation listed here.)
I think Matt Barber even had a case where removing a [trigger]
object and replacing it with bare wires (and just depending on creation order) generated enough of a performance difference in a complex patch to warrant doing it. (Edit: this may have been in an abstraction, in which case the speedup would be multiplied by the total number of abstractions used...)
It's too bad that message-passing overhead makes that much of a difference. And while I can think of a potential speedup for the case of [trigger]
, I'm not sure there's a simple way to boost message passing performance across the board.
Controlling Ableton effects
The most powerful way to control ableton live devices is using Max for Live API, Using it you can comunicate from Pd with Max for Live via OSC messages. It can be ok if you have good patches in Pd and don't want to rewrite all in Max.
The other way is sending MIDI messages to Ableton and manually map each message you are sending from Pd.
If you are in mac, you can use IAC driver.
In Windows, some software to do the same... I don't use Windows so I only remeber one option, which is loopmidi.
Once you solved the comunication bridge of MIDI data with Ableton and Pd I recommend you to use ELSE library, which is at disposal in deken. It comes with some facilities to compose and send midi messages from Pd, and comes with a Live Electronics Tutorial which have a session dedicated to MIDI messages.
Purr Data GSoC and Dictionaries in Pd
If you need to store a bunch of key/value(s) pairs as a group (like an associative array does), a [text] object will allow you to do that with semi-colon separated messages.
Performance is abysmal, though -- I had guessed this would perform linearly = O(n), and a benchmark proves it.
-
The array y range is 0 to 3000 (= 3 seconds). 10000 lookups per 'pd benchmark'.
-
I had to abandon the test because, long before 100,000 elements, each iteration of the test was already taking 4-5 seconds.
-
[* 1.2]
-- in a search, failure is the worst-case. This is an arbitrary choice to generate 1/6 or about 16% failure cases.
I translated this from a quick benchmark in SuperCollider, using its associative collection IdentityDictionary.
(
f = { |n|
var d = IdentityDictionary.new;
n.do { |i| d[i] = i };
d
};
t = Array.fill(200, { |i|
var n = (i+1) * 1000;
var d = f.value(n);
var top = (n * 1.2).asInteger; // 16% failure
bench { 100000.do { d[top.rand] } };
});
t.plot;
)
-
SC's implementation is a hash table, which should give logarithmic performance. The graph more or less follows that.
-
SC is doing 10 times as many lookups per iteration, but:
- In this graph, SC's worst performance between 46000 and 56000 elements is 17.4 ms.
- If I look up in the Pd 'bench' array at 50 (51000 elements), I get 3082.
- Extrapolating for SC's number of iterations, that's 30820 / 17 = 1771 times slower on average per lookup.
- Since Pd is linear and SC is logarithmic, this ratio will get worse as n increases.
"This isn't fair, you're comparing apples to oranges" -- true, but that isn't my point at all. The point is that Pd doesn't have a properly optimized associative table implementation in vanilla. It has [text], but... wow, is it ever slow. Wow. Really not-OK slow.
So than people think, "Well, I've been using Pd for years and didn't need it"... but once it's there, then you start to use it and it expands the range of problems that become practical to approach in Pd... as jancsika said:
It's hard to know because I've gotten so used to the limitations of Pd's data types.
That shouldn't be considered acceptable, not really.
TL;DR I would love to see more robust and well-performing data structures in Pd.
hjh
Few questions about oversampling
Hi,
About a year ago I started to learn a bit pure data in order to create a patch that would act as a groovebox and that should perform on limited cpu resources since I want it to run on a raspberry pi. First I tried to make somekind of fork of the Martin Brinkmann groovebox patch, even if it allowed me to learn a lot about data flow I didn't went to the core of the patch tweaking with sound generation. This led me to end this attempt at forking MNB groovebox patch because even if I could seperate GUI stuff from sound generation and run it on different thread ect... I couldn't go further in optimization in order to reduce the cpu use.
Then a few weeks ago I decided to start again from scratch my project and this time I wanted to be more patient and learn anything needed in order to be capable of optimizing my patch as much as possible. After making a functional drum machine which runs at 2/3% of cpu with 8 different tracks, 126 steps sequencer, a bit of fx ect... I tried to find synths that would opperate well aside the drum machine. And I basicly didn't find any patch that wouldn't use massive amount of cpu time. So I created my own synths, nothing incredible but I'm happy with what I got, though I noticed some aliasing. I read a bit the floss manual about anti aliasing and apply the method used in the manual(http://write.flossmanuals.net/pure-data/antialiasing/), it work well but my synths almost trippled their cpu use, even if I put all my oscilators in the same subpatch in order to use only one instance of oversampling.
I didn't tried to oversample it less than 16 time but since oversampling is so cpu intensive I'm wondering if there's no other option in order to get a good sound definition at a lower cpu cost. I'm already using banlimited waveform so I don't know what I could do in order to limit the aliasing, especialy for my fm patch where bandlimited waveform isn't very useful in order to reduce aliasing.
Since I want to have at least 4 synth track with some at least one synth having 5 voice polyphony I want to know what the best thing to do. Letting FM aside for this project and use switch~ for oversampling 2 or 4 time my synths that use bandlimited waveform ? Or should I try to run different instances of pd for each synth and controling it from a gui/control patch with netsend(though it wouldn't bring down the cpu use at least it would provide somekind of multithreading for my patch) ? Or is there another way to get some antiliasing ? Or should I review lower my expectation because there is no solution that could provide a decent antialiasing for 4 or more synth running at the same time with a low cpu use in pure data in 2021.
Thanks to everyone that would read my topic and try to give some advice in order to get the best antialising/low cpu use solution.