Dr. Hernandez seriously doesn't get enough credit for all the work he does for this community.

@whale-av I think I understood everything about that floss tutorial EXCEPT the bit about the [hip~ ]. How does [hip~ } effectively translate a signal in the same way {-~ 1] does?

@ricky I get this when opening the help file grambilib~ v1/grambipan~.pd_darwin: mach-o, but wrong architecture

Any idea how to proceed?

sure pm me

@maxdavidson Some links you can check out:

https://puredata.info/docs/faq/macosx
https://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7
http://forum.pdpatchrepo.info/topic/7236/pd-extended-has-stopped-working-on-mac-help/11

Also, make sure you have X11 installed. pd needs that to run. Used to be installed by default but every since OS 10.6 or so Apple stopped including it in their operating systems.

@maxdavidson What kind of computer do you have and what OS ? What version of pd are you installing?

@csschupp I mean...we can help you for free too! Are you allowed to post your patch?

@mx This could take a long time to type out the explanation for all this. I'd be glad to help you. but here's some stuff you might want to look at first. Your patch is essentially just G09.pitchshift from the pd tutorials. Check out that file for some documentation. Also, here's what Miller has to say:

http://msp.ucsd.edu/techniques/latest/book-html/node115.html#sect7.pitchshift

and more specifcically:
http://msp.ucsd.edu/techniques/latest/book-html/node125.html

After reading, let me know if there's anything you would like help with understanding

edit: less technical explanations:
http://www.katjaas.nl/pitchshift/pitchshift.html
http://pd-tutorial.com/english/ch03s07.html
And a vid for max instead of pd but the concepts are the same

@moih Usually the help file will tell you. Although the help file for this particular object is pretty sparse. I shined my phone light into my mac's camera and would get values around 9000 before the number boxes simply outputted a "+" which typically means overload. You might have to do some math to get these sensors numbers into a reasonable range.

@moih {expr ($f1 /HighestIncomingValue)*127]

Or in english: Your incoming sensor data, divided by the max level possible, multiplied by 127. This scales your incoming range to 0-127

@mholes1 What does your patch look like?

@solipp NIce! Happy new year

@mx Try adding [prepend set] before the message boxes at the bottom. The "set" message will clear a message box which will then display whatever comes after it.

@sglandry said:

Thanks for the patch. How does sending out multiple master_bang 's work? Does whatever loop you start playing first basically become the "master" track that controls all the other ones? Or is there some other global master bang logic that I'm not seeing.

If i remember correctly, I usually just set "track1" to be the "master track". I would record this track first, and however long it was (in ms) would be the length of the master loop. Whatever you decide is going to be the master loop should be the longest recorded sound, because when it repeats any other tracks that are longer will cut off and repeat as well (if you choose to sync them).

When the "master track" repeats, it sends a bang (via [s master_bang]) out to all the other tracks with the "sync_to_master" box checked (well, it gets sent to all tracks regardless, but only tracks that are synched let this bang pass through). The "sync_to_master" box essentially just controls the [multiplex] object, which switches between the sources of the bangs that tell the track when to repeat. You can have a slave track repeat when the master track repeats, otherwise you can just have it repeat itself asynchronously, or just manually when you click on the bang itself.

Whats the difference between [timer] and [realtime]? Do they essentially do the exact same thing?

As far as I know, [timer] measures logical time, and [realtime] measures elapsed real time. Someone smarter than me on here can tell you the difference.

Whats the easiest way to make sure all my reading and writing to buffers are synced up?

Here's an unfinished patch I began a long time. Inspired by Jamie Lidell:
looper-with-master-sync.pd

Check out what I did for the synchronization. I can explain anything in detail if you'd like.

Poke~ with count~ as an index of table location (in samples) to make sure I'm writing to the correct location in the buffer? Or tabwrite?

As far as I can tell they accomplish the same thing. [tabwrite~] is Vanilla compatible.

What exactly is "interpolation?" (tabread vs tabread4)?

Essentially, smoother playback. More noticeable when playback speed is reduced. See here: Section 3.4.1.2 at http://www.pd-tutorial.com/english/ch03s04.html

Why do I need to use a phasor object to read through tabread, and not just the output of count?

You don't. [phasor~] simply generates a ramp from 0 to 1. You can manipulate this function to read through an entire array, but by no means is it the only way. Using [vline~] is another popular alternative.

@lead This link doesn't work

This is a big project. I know that modern DAWs like ProTools and Logic accomplish it like this:

1. Analyze audio for transients
2. Use an algorhithem to determine a pattern of evenly subdivided transients
3. Measure the time between these transients and convert to BPM

So essentially you would have to find ways to implement this in pd

@gav_hood Here's another way to look at it:

You omit an argument from {* ~] if you want to modulate an audio rate signal with another audio rate signal. You use an argument if you want to perform math on a single audio rate signal (e.g. amplitude scaling etc.)

@gav_hood Since your [* ~] right below your [ead~] object is an audio rate object (meaning it has a tilde ~ at the end), it doesn't store values like a non audio rate object would {e.g. [* ], [+ ], [/ ], etc.) because all its inlets are "hot"--if that makes any sense. In other words, the result of your [/ 127] division does not get stored in the right inlet of your [* ~]. Therefore, unless [* ~] receives a non zero number from both inlets simultaneously (e.g. if you only hit that bang above [ead~]), then your output will be zero (no sound), since you are multiplying by zero.

@gav_hood Also, try this to make sure it's not a MIDI problem: