• rjp9

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

    posted in tutorials read more
  • rjp9

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

    posted in technical issues read more
  • rjp9

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

    Any idea how to proceed?

    posted in extra~ read more
  • rjp9

    sure pm me

    posted in technical issues read more
  • rjp9

    @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.

    posted in technical issues read more
  • rjp9

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

    posted in technical issues read more
  • rjp9

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

    posted in technical issues read more
  • rjp9

    @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

    posted in technical issues read more
  • rjp9

    @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.

    posted in technical issues read more
  • rjp9

    @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

    posted in technical issues read more
  • rjp9

    @mholes1 What does your patch look like?

    posted in technical issues read more
  • rjp9

    @solipp NIce! Happy new year

    posted in patch~ read more
  • rjp9

    @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.

    posted in technical issues read more
  • rjp9

    @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.

    posted in technical issues read more
  • rjp9

    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
    upload-651074a6-405c-456a-bfc7-a8f0d6607139

    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.

    posted in technical issues read more
  • rjp9

    @lead This link doesn't work

    posted in patch~ read more
  • rjp9

    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

    posted in technical issues read more
  • rjp9

    @gav_hood Here's another way to look at it:upload-dba9e990-8549-4281-b051-ee0533d6cd7f

    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.)

    posted in technical issues read more
  • rjp9

    @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.

    posted in technical issues read more
  • rjp9

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

    upload-f23d1f99-f980-4457-b12c-390bbfa3c2ad

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!