• defaultxr

    Hi,

    i searched the forum for information on hiding the menu-bar in Pure Data but all i found were topics about GEM. i'm wondering if it's possible to hide the menu-bar on a specific patch or sub-patch in pure data, WITHOUT hiding it globally. i would assume it could be done via pd's internal messages but i've investigated them as best i could to no avail. i've seen that in the upcoming 0.43 release of pure data, it can be done via GUI plugins, but i'm still using 0.42.5-extended so i'm wondering if there's a way to send a message to the Tk interpreter somehow that could hide the menu-bar for a specific patch or sub-patch...

    Any help would be greatly appreciated.

    posted in technical issues read more
  • defaultxr

    hi everyone,

    i've written a few abstractions and i've decided to upload some of them (most of my useful ones are here). i use pd-extended and i haven't tested whether they'll work on vanilla pd.

    there are a lot of small but handy abstractions in this package as well as some more complex sequencers.

    i've also included introduction patches which give a quick explanation of almost all the abstractions included.

    out of the "small but handy" abstractions i find [map] the most useful.

    some of these are really messy, some aren't well-documented, some may have bugs, and some were pretty much ripped off from other people (i've tried to give credit though).

    also, there may be a few abstractions you'll want to edit because i have some of my path-names in them. i think [snd~] and the sequencers have them. your best bet is to open them in a text-editor and search for "/home/modula" (without quotes) and replace the directory with whereever you store your sound files or data, respectively.

    anyway, hope you enjoy these, and if you have any questions, feel free to reply and i'll elaborate as much as possible.

    Edit: i'm now maintaining these on github. the latest versions of them will always be here.

    posted in abstract~ read more
  • defaultxr

    hi everyone. i've been messing around in pd for quite a while now and after the initial hump of learning how it all works, it really clicked with me. i really love this software and as a way of giving back to the community i decided i'd post two of my sequencers here.

    the first one, drumseq.pd, is a simple drum sequencer made primarily of 4 rows of toggle boxes. if you send bangs or floats to the inlet, it will send bangs to each outlet depending on whether the toggles for the current step are checked.

    the second one, anaseq.pd, is an analog sequencer which allows you to output values from 0 to 127 for each step. you can only edit one "row" at a time but there are still four outlets. by default all outlets are outputting the data from pattern 0, but this can be changed with a "play [pattern] [outlet]" message to the inlet.

    both sequencers currently only support 8 patterns (numbered 0-7) but because of the way they are designed, it wouldn't be too difficult to increase that number later on. i didn't include a lot of documentation for each sub-patch, but in the main patch, there are a lot of comments which should help you to understand how it all works.

    some of the other functions these sequencers have are:
    * pattern copying
    * saving of patterns
    * (automatic) loading of patterns
    * full control via messages to the inlet

    i tried to give each sequencer a minimal yet useful interface. there are three buttons on the top row: save (in red), copy (in orange), and go (in green). save will save the pattern to a file (be sure to look inside the sequencers before you press this - right now it will try to save to the path i use, which likely doesn't exist on your system). copy will by default copy from the previous pattern to the current one. "go" will play the current pattern (you can edit patterns without having to play them - hopefully this will make it easier to use the sequencers in a live/improv setting).

    i'm bad at explaining things but if you have questions i'd be glad to answer them. hopefully these abstractions will be of use to you. like i said, i've tried to make them as general/open-ended as possible.

    p.s.: i've also included "bpmm.pd" which is a simple abstraction for outputting numbers at a certain bpm. this has four outlets - the first outputs a bang on each downbeat and will output a "time" message with the length of each bar in milliseconds as well as a "freq" which gives the frequency needed to synchronize a phasor with the bpm (you can route the bang to a [0( to reset the phasor so they stay in sync). the second outlet outputs 0-3 for each fourth note, and the third outputs 0-15 for each 16th note in the bar (connect this third outlet to the inlet of the drumseq or anaseq to run them). the final outlet of the bpmm is a signal outlet, which is a phasor~ output sync'd to the bpm. if you turn off the bpmm (via the toggle) then the phasor stops as well.

    http://www.pdpatchrepo.info/hurleur/seqs.zip

    posted in abstract~ read more
  • defaultxr

    Hello, sorry if this has been asked before, but I searched the forum as well as google and I didn't find anything. Is it possible to detect whether edit mode is active?

    Basically what I'm trying to do is use the qwertyuiop keys to toggle on and off different sounds (q multiplies audio signal by 1, then pressing q again will multiply the signal by 0). I have the toggling working already, but I'd like to be able to add new objects in edit mode... The problem is that [key] still detects keys during edit mode, which could result in unwanted toggling of sounds.

    Any advice would be much appreciated.

    posted in technical issues read more
  • defaultxr

    For bass drums/kicks, the simplest is probably something like:

    [500, 0 100(
    |
    [line~]
    |
    [osc~]
    |
    [*~ 0.5]
    |
    [dac~]

    For a snare, try:

    [noise~]
    |
    [*~]\_[line~]\_[0.5, 0 100(
    |
    [dac~]

    The second line in the snare example is a [0.5, 0 100( message connected to a line~'s left inlet connected to the right inlet of *~, in case it's not clear (i don't know how to do ascii pd patches)

    posted in technical issues read more
  • defaultxr

    alexandros, yes, sorry about that. here's [lb].

    p.s.: there are newer versions of these sequencers as well as many other abstractions i've made in this topic, or you can check the github page for my abstractions, which is even more recent.

    http://www.pdpatchrepo.info/hurleur/lb.pd

    posted in abstract~ read more
  • defaultxr

    here are a few tips for all of you:

    when you make a complex patch with lots of sends and receives or other objects that might need a $0 in the name, instead of typing something like , type . that way, you can still use pd's find to search for "s foo-" (just make sure the "whole word" box is unchecked).

    also, to have multiple things coming from one object, i like to do something along these lines:

    [map 60'1000 58'500 55'500 53'1000]
    |
    [s2l ']
    |
    [unpack f f]

    that way, you can get two numbers from the same [map] just by splitting them by an apostrophe. maybe you'd prefer to use multiple maps but i find it's easier to sync them this way.

    [map] is sometimes good as a replacement for [select] especially if each outlet of the [select] is connected to a message box anyway. another thing i use [select] for is to select only certain things. however, sometimes i want all instances of something to go to the same place. a good replacement for [select] in this case is [unmap].

    [unmap]'s arguments are a list that its input (on the left inlet) is matched against. it will output the input's index in the list if it's matched, but it won't output if it isn't matched. since [unmap] only has one outlet, you can use it as a replacement for [select] just by connecting [unmap]'s outlet to a [bang]. that way, you don't have to connect each of [select]'s outlets to the same object; you only have to connect it to one! pretty handy in my humble opinion!

    anyway i really hope these abstractions do their job and abstract away some common patterns. like i said, i'm most proud of [map] - it's very versatile and i've tried to make it as open-ended as possible so it comes in very much handy!

    feel free to share some tips if you discover any clever ideas! :D

    posted in abstract~ read more
  • defaultxr

    wow, awesome! EXACTLY what i needed, and it works perfectly on my system! thank you very much Maelstorm! :)

    posted in technical issues read more
  • defaultxr

    since i uploaded mono, i managed to work out the bugs and altogether made it more efficient. here's the updated version.

    http://www.pdpatchrepo.info/hurleur/mono.zip

    posted in patch~ read more
  • defaultxr

    whoops, sorry about that. here's [num].

    by the way, [mono] isn't perfect. i've noticed it has trouble when two keys are pressed simultaneously. it'll still work fine if you press the keys to "un-stick" them, but it shouldn't happen at all. i'll re-post [mono] in its own thread once i've fixed all the bugs. for the most part, though, it works pretty well. hope you find it useful.

    http://www.pdpatchrepo.info/hurleur/num.pd

    posted in patch~ read more

Internal error.

Oops! Looks like something went wrong!