@willblackhurst Good catch. Alternatively, you can add it to your start up preferences where it may stay for so long that you forget it's not part of Vanilla

@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'?

@whale-av said:

P.S. I noticed with your original patch that the input gain 15 did not seem to have loadbanged in every track sub-patch. Very strange.

It's because some of the loadbangs are messages, not objects.

@oid I was slow on the draw again, but this time I'm not deleting my post! No offense

@nicnut You're losing sync because you have distinct metro objects for sixteenths and triplets. The precision limits of Pd floats means you can't always set those metros to exact ratios of each other. A way to solve the issue is to make a common metro and derive the sixteenths and triplets from it, for example:
triplets and sixteenths.pd

@whale-av Thanks. RE 2 mk4s, don't bother checking, I was just curious how you'd know which option to choose when presented with "would you like the Ultralite mk4 or the Ultralite mk4?" I see the potential for that in Discovery and Pro Audio Control, and can imagine a similar choice in Pd's Media->Audio Settings. At least in Pro Audio Control, at the bottom of the Device page, in teeny tiny print at the bottom, there's the device serial number....

Update: RTFM! pg 12, item 8: "click to rename the interface"

Jeez, I finally found the issue: the MOTU driver was out-of-date (having been installed in March 2023--time is clearly speeding up)! After installing the most recent version, Pd 0.55.2 has the same <10 mS latency whether it is started first or second.

I wonder if the alpha-pros would never share audio interfaces, and instead use one for QLab and another for Pd?

@whale-av, I want to ask you more about your experience with the mk4. Have you ever installed 2 on one machine, and if so, how does Discovery and Pro Audio Control distinguish between them, since they are the same model? And can you tell me more about why you think the mk4's web interface is better than CueMix? I only use the routing matrix and clock source, and am ignorant of all the rest of its features.

@whale-av said:

I am pretty sure that it was made by @jameslo

Probably not...it doesn't look familiar....

@whale-av My fancy colleagues look down on the ultralight, I have no idea why. I worked in 4 different theaters that owned the mk3 and was always happy with them.

Is it true in my case that both Pd and QLab are accessing the same MOTU driver, and that that driver implements the coreaudio API, and that that API governs how applications share drivers?

Is there any way to check what buffer size the MOTU driver is using?

One of the tests I ran this morning was to start QLab, then start my Pd patch, then quit QLab and measure. Same long latency. Maybe I should try switching Pd away from the ultralight and then switching back before testing? That would test your hypothesis, wouldn't it? Better yet: run QLab, quit QLab, run Pd, then test.

I ran a show with QLab and hosted a live vocal effect on the same Mac. Here was my setup:

What's odd is that Pd would have ~300mS of latency if my effect patch was started after QLab, but only about 10mS if it was started before. This morning I finally upgraded to Pd 0.55.2 from 0.55.1 and tested with the latest version of QLab, and latency is still dependent on startup order, although only about half as bad (~150mS) in the worst case (and also ~10mS in the best case). Pd's audio settings are 44100, 3 mS delay, 64 sample buffer size, and not using callbacks.

Does anyone know why Pd's latency is dependent on the order it is started? Are there other tests I should perform to understand better what's going on? This behavior is somewhat surprising to me because 2 years ago I ran a much more complicated show involving live effects implemented with REAPER, plugdata, VSTs, and OSC--I don't remember there being any issues.

And if you print the output of the pack on the left, you'll see that it prepends "list" to [samplerate 44100(