@chvolow24 Not sure if this is relevant, but when I last tested with no flags, things worked as you're expecting. https://forum.pdpatchrepo.info/topic/14895/controlling-pd-over-internet/2

@blindingSlow I think you're right about why 48 Hz works.

A lot of oscillators use [phasor~] to compute each cycle, so you could use that to write your display. I found a way to do it using Gem years ago and never looked for another way, but I think nowadays there are other oscilloscope abstractions available. Here is a variable duty-cycle triangle wave thing. Click on [create, 1( first to open the Gem display window.
one cycle display.pd

PS is it still called "duty-cycle" if it's not a square wave? I'm not a synthesist.

@dvd01osclfo Consider using @oid's method above, it's a little less arcane than that compound message idiom. Otherwise, here are some relevant sections of array help:


Also, an easy way to check what values are in an array is to right click on it, select properties, and then list view.

@dvd01osclfo I'll assume that array98 is somewhere off-screen. Your initialization message is still weird. First of all, you no longer need that [f $0] because you didn't want to use it anymore to prefix your array name. Next, you still are not initializing your array from the beginning, index 0, and I'm not sure what "pitches" does in that message. Look again more carefully at that help page. The format of that second line of the message should be <name of the array><start index><value 1><value 2>.....

You're almost there. I suggest you just create an array and work on sending it messages until you figure out what's going on. Signing off until tomorrow am.

@dvd01osclfo I know you will!

@dvd01osclfo Create an array, then right click on it and select help. On that first help page there are examples without the $0- prefix. Next, click on [16.more.arrays.pd( which opens another help window. The first paragraph tells you how to set the start index and values in a message. If you look back at my other reply you can see how Pd interprets your first 440 as the start index.

@dvd01osclfo OK! Issue #1 is that on the left, you made loadbang a message and not an object. So that means it never output a bang, and so you didn't get Pd's error message about issue #2, which is....that you never made the array $0-pitches! Just click on that nice compound message you made and you'll see.

But there's yet another issue: in that same nice compound message you made, $0 doesn't work. In messages, $n is interpreted differently than in objects. So what you need is something like this:

But now you would have seen that your pitches array hadn't been initialized. That's because you need to specify the start index first, before the values. As written, you've requested to write the values 494 523 ... 880 starting at index 440, which is way past the end of the array so it does nothing.

And then, I think, finally, you would have wondered why the pitch of osc~ wasn't changing. It's because you're banging tabread, not telling it which element to read by giving it an index number. Does that make sense?

@manuels Yes, it was the phase shift I was referring to, and I wasn't aware that one could low-pass filter without phase shift, although now that I see your patch it seems obvious. It even looks like what I was proposing, a moving RMS window, might be another instance of a zero-phase lowpass filter:

I wish I knew more about filters, statistics, probability....

I'm trying to use [array random] to create a random number generator that outputs numbers in a similar distribution to a real-world process. In the snapshot above, the "distribution" table is a histogram of 285 points of real data, and I'm speculating that if I had access to more data, the curve would become smoother.

The "simDist" table is just my eyeball attempt to make the idealized version of the real histogram. In tests, it works fairly well, but I'm wondering if it would be better if it was arithmetically derived from the "distribution" table, e.g. uh, I dunno, a moving N-point RMS? I'm sure a data scientist would say "it depends what you mean by 'better'", but I'd be interested to know what options there are and what each is good for. Somehow, low pass filtering doesn't feel right to me because it's a histogram.

@lyric Here's an idea: at some point you may want to want to put a volume envelope on each grain--it helps with popping, and at higher frequency grain triggers it can filter out high frequencies. I've used cosine-shaped envelopes, but it could be anything you want. Anyway, grain envelopes would be easier to implement if you made [line~] go from 0 to 1 and then performed the start and end sample calculations after [line~] but before [tabread4~]. Now you can easily reuse that same "normalized" [line~] range to calculate your envelope. See what I'm sayin'?