• beep.beep

    @RetroMaximus Hi there, I see a couple of issues that might explain what you're experiencing (although no guarantees, since I'm just looking at a screenshot without being able to debug the patch...)

    Dollar sign variables function differently in objects than message boxes. Your unpack & pack are objects, which means $1 through $16 are looking for creation arguments to be passed from the parent, not values that are being passed & unpacked from the list. What you probably wanted there is [unpack f f f f f f f f f f f f f f f f(, which will send out the 16 values in right-to-left order from the outlets.

    The result being sent to the outlet is all ending up on one line of the textfile object because you are sending one "add" message with all of the values at once, whereas it sounds like you want to serialize them (textfile will create a new line for each new "add $1" message). Here's a simplification of everything between your [list] and [outlet] in the top screenshot:

    [list]
    |
    |$1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16(
    |
    |add $1(
    |
    {outlet}

    As for having to push a button twice for everything to work: that sounds very much like a problem with undefined execution order. Just for example: your [$7] object (again, I don't think a dollar sign variable is what you wanted there... it's looking for a 7th creation argument, probably failing & defaulting to zero, and effectively becoming a [f] object) is sending to a bang and the buildactivepatternPath subpatch, but you haven't defined the order. Basically anytime you need to control the order of operations (which is 99.9% of the time), use a trigger object, like [t b f] or [t f b].

    Not to only dwell on bugs though... your vertical lines & overall patching style make for a very clean & readable patch, so nice work there! :trophy:

    posted in technical issues read more
  • beep.beep

    @Johnny-Mauser For sure... (at the risk of veering somewhat off of the original topic) Here's the 64-bit [helmholtz~] I compiled for Mac:

    helmholtz~.pd_darwin
    (by the way, @katjav included a README with build instructions in the helmholtz download, and it worked right out of the box for me, so I'd imagine you can compile for whichever platform/architecture you like)

    The only other two things I ended up recompiling for 64-bit Pd were [pvoc~] from the bsaylor library, and the iem_dp library for double precision operations within normal Pd. (funny that you should mention double precision as well... maybe the latter could be of use to current you, not just future you!) I uploaded both of those in previous forum threads:

    the pvoc~ one
    the iem_dp one

    posted in technical issues read more
  • beep.beep

    If I may weigh in (on both the pitch detection & 32/64 topics):

    I have tried all three of the aforementioned objects, and personally found [helmholtz~] to work best for my uses. I can't say I was extremely scientific in my comparisons, but I generally got the sense that it performs a bit better than [sigmund~].

    When I first began migration from extended to 64-bit vanilla, all of the 32-bit externals I was using needed to be replaced, and [helmholtz~] was the one I missed the most. I replaced it for a while with [sigmund~], but eventually I went & compiled a new [helmholtz~] from source against 64-bit vanilla, which is working fine.

    Now, as for comparing performance of 32 vs 64 bit Pd in general (very much FWIW... I'm on MacOS, not Windows, and I have no technical knowledge to back these observations up): a couple years ago I did test my most CPU-intensive patch in both 32 and 64 bit vanilla, and found a modest ~15-20% CPU performance boost (according to the load meter) when using 64-bit. I remember seeing some discussion of this on the Pd-list a while back, it might have been this thread. I did not compare memory usage between versions, so I can't speak to that.

    posted in technical issues read more
  • beep.beep

    @jacoblast I’m using the same setup (Mojave + 0.49-1). I find it to be pretty stable in general, and definitely more so than the combination I started with years ago (Lion + Pd-extended, vanilla 0.46-6). Back in those days, I had something similar to what you’re describing happen a lot, where Pd would freeze and a zombie process would gobble 100% of the CPU until I would manually kill it. I never did track down the absolute cause, but I suspect it might have been a tcl issue due to my inadvisably-huge GUI for my patch. I don’t recall opening/closing patches or switching DSP to be a problem, though.

    I suppose if I were troubleshooting this now I’d ask myself:
    -does it happen with any particular patch?
    -could it be an external library that I’m loading?
    -am I running any other audio software that might be locking up Pd?

    I believe you can start Pd from the command line with flags that post errors to the terminal, but I don’t remember offhand... I think -stderr is one (?), but can’t remember specifically at the moment. Maybe that could give you some insight into what’s happening once Pd hangs?

    posted in technical issues read more
  • beep.beep

    If you're using a recent Pd vanilla (0.49), you can do this easily using the built in [array] object. You can read more about it in the help browser: Pure Data/5.reference/array-object-help.pd

    If I were tracking the play counts of 200 audio files, I would use [array define playcount 200] for storage of the stats, with each index representing a specific track. When a track is played, get the previous count at that index using [array get playcount], then add 1 to that total and use [array set playcount] to update the index. Finally, when you want to find the index with the greatest number of plays, use [array max playcount].

    Things would get a little more complicated if you wanted a top 10 most played, etc., but totally doable either in vanilla or with externals.

    UPDATE: @whale-av edited his reply to mention this too!

    posted in technical issues read more
  • beep.beep

    I discovered by accident a while ago that this undocumented functionality is actually built in to the [gemwin] abstraction. (I can't test this on versions of Gem where [gemwin] is an object that cannot be opened, which I've come across in the past, maybe in Pd-Extended?)

    You can just do this (send "debug 1" message to turn on FPS output):

    |debug 1(
    |
    [gemwin]
    |
    [route real_fps]
    |
    |here'syourFPSoutput\

    @korakinos I haven't looked at your framerate patch, but as you mentioned, [avg~] as a smoother requires DSP... if the goal is to keep FPS high, you wouldn't want unnecessary calculation going on (indeed, if you're doing any audio at the same time as your visuals, best to run it in a separate Pd instance). The other external objects you mentioned would work, or there are a number of vanilla ways you could slow/smooth output in the control domain. I myself send the real_fps output to a vslider as my FPS meter—I don't use smoothing, but I only turn on the debug output for testing purposes, never in performance.

    posted in pixel# read more
  • beep.beep

    @jancsika Congrats, and many thanks for including the "diff view" idea we were discussing last week as a part of this!

    posted in news read more
  • beep.beep

    @jancsika Brilliant!

    Yes, I see how the situation becomes complicated very quickly—my original mental image was of a single Pd canvas with black (unchanged), green (new/modified), and red (deleted) Pd objects, perhaps with view filters to compare versions. But indeed, the question of how to handle canvas resizing, subpatch/abstraction changes, etc. within a single window sounds like a messy one to answer.

    Also, the notion of recording every canvas edit poses a useful question to me: what level of detail do I really want/need to save as I develop a project? There have certainly been times when I wanted quick access to an old version of a part of my patch, but if I were to comb through a sequence of hundreds of individual edits to find the right state, I could see this ultimately being more work than simply redoing the work anew. I assume this is the idea behind “commits” in Git, which represent meaningful milestones, so for now I’ll keep studying up & see if I can get a good workflow going that way.

    posted in technical issues read more
  • beep.beep

    @jancsika Thanks for your insights! That makes sense to be selective about which project files are tracked. I have a couple of subdirectories for saving more-or-less temporary txt & wav files, so perhaps I will .gitignore those. (I haven't tested, but I had considered the nightmare possibility that writing a huge wav file to the tracked repo would cause Git to gobble up resources/memory by trying to see changes in the file... but perhaps there are protections or file size limits for such scenarios?)

    And thanks also for the notion of writing descriptive commit messages, I can definitely understand the need for clarity, as I wouldn't be able to discern much more than a basic edit in looking at changes in Pd code. Although, as an aside, that thought does make me wonder what would be involved in creating a visual "diff" view of canvases within Pd's gui (or even a more complete built-in Git integration!). Easy for me to speculate, of course, I'm sure it'd be a ridiculous amount of work under the hood for questionable gains.

    posted in technical issues read more
  • beep.beep

    Hi all, I'd be curious to hear from anyone who uses Git for version tracking of their Pd projects. I'm a Git noob... just getting started with setting up a local Git repo on my computer (no need for Github in my case), and I have a couple of questions:

    -Is there any risk of Git causing issues if I run my Pd patches directly from a Git repo? Is it better to use a separate development repo/directory & then copy the latest version to a separate, non-tracked directory for actual Pd use in concert?

    -Is there a way in Git to associate evolving versions of all dependencies in various locations? In my case:

    • Pd performance patch directory (with subdirectories containing abstractions)
    • ~/Library/Pd (my externals directory)

    I suppose I could create a new repo, copy all of my files into it to begin version control, do all of my development there, and then copy/overwrite all files back to their original locations when I want to move from development to performance, but there's got to be a better/safer/neater way to do it all without shuffling files all over the place manually.

    posted in technical issues read more
  • beep.beep

    @cmovvv Hi there,

    Yes, the left inlet of most objects in Pd is the "hot" inlet, which means the object will output immediately when anything is sent to it. "Cold" inlets are for setting values without causing the object to output, which is why you can send floats to the middle/right inlets of [pack] without triggering your envelope.

    There are several ways to prevent immediate output, here are a few that come to mind:
    coldpack.png

    It's also worth noting that you have a problem with one of your number boxes (the one displaying "69.92" in your screenshot) in that you haven't defined the execution order being sent to [pack f f f}, Always use a trigger object to ensure that you're sending output in the correct order (as I did with my rightmost example), otherwise you will inevitably run into problems. I see that you have used several triggers elsewhere, but most of them look unnecessary — the top right one is sending the float first & then a bang second, but because the float has already been sent to the hot inlet of [* }, the bang is redundant. (if you check with [print] you'll find that you're actually sending the result of the multiplication twice, but in this case no harm done)

    posted in technical issues read more
  • beep.beep

    @RonHerrema Hi there,

    I'm not the best person to answer your first question, as I myself have never tried to install a tcl plugin, but my uninformed guess would be that you need to add the tcl file to a path that is being searched by Pd at startup, such as the directory where Deken (the "Find externals" tool in the Help menu) can automatically create for you when you first install externals. Maybe check out this post?:
    https://forum.pdpatchrepo.info/topic/9960/tcl-for-a-rainy-day

    As for your second question: yes, the latest Pd vanilla (0.49) has new intelligent patching shortcuts built in, and they're awesome! Check out these links for descriptions & video demos:
    https://github.com/pure-data/pure-data/pull/374


    posted in technical issues read more
  • beep.beep

    @uptick Hello there,

    I took a somewhat similar path in that I began learning SuperCollider, and then found myself decisively drawn in to the world of Pd. From my experience, I'd say the suitability of either depends greatly on your background—would you consider yourself to be comfortable with coding, or does a visual dataflow language allow for more clarity? In my case, obviously the latter is true (which is why I took to Pd), but I have friends with coding chops that are able to realize their ideas in SC more easily/quickly/efficiently.

    The main breakthrough that I had as a Pd beginner was in studying the work of advanced Pd programmers (open source is a beautiful thing!), and discovering the power of abstractions. I spent hours/days/weeks/months connecting hundreds of objects together, copying & pasting, and debugging messy canvases before I learned how quickly the same work can be realized in minutes with a set of abstractions. I'm sure the same is true in SC, but I myself never got beyond the basics there.

    As for versions: definitely not Extended, it's no longer supported. I use vanilla, and download any externals that I need with the Deken plugin ("Find externals" option in the help menu). Purr Data is a great Extended alternative, with many externals already pre-installed, and an HTML5 gui. I use it for certain applications, but my main performance patch is vanilla-based.

    Learning resources: this forum & the Pd-list archives (which you can access through the top menu of this forum above) are good to search through for specific questions, sometimes via google. I also found this series of videos very helpful as a beginner:


    And don't forget to go to Pd's built-in help browser and check out Pure Data/2.control.examples & Pure Data/3.audio.examples (the latter of which teaches the basics of DSP programming in Pd, and also realizes more general computer music technique as presented in Miller Puckette's book.

    Enjoy!

    posted in technical issues read more
  • beep.beep

    Thank you both for the great ideas! Much simpler than what I was trying to do, so yes indeed, I had thought myself into a corner there....

    I like the simplicity of the [lop~] approach, however I'm guessing the dual [line] method will work best for me in terms of efficiency (I may eventually have hundreds of these running at once). Adding a multiplier sounds like a fine idea; I think I'll also shift the random range to be centered on zero (adding a [- 0.5] after [/ 1000]), so that the multiplier will expand the output in both directions.

    Again, many thanks!

    posted in technical issues read more
  • beep.beep

    Hi folks, I’m finding myself a bit stuck, and wondering if anyone might have an idea for an efficient way to emulate a certain physical behavior. Consider this example:

    [metro 1000]
    |
    [random 1000]
    |
    [/ 1000]
    |
    [pack f 1000]
    |
    [line]

    The output will be a series of random one second ramps between 0-1. This gives a rough impression of drifting/floating about the range, however the change in velocity between each ramp is instantaneous & jagged.

    What I’m wondering is: how can one smooth out the transitions between ramps, and give the output a sense of inertia/momentum, while preserving the unpredictable, random motion?

    I am aware of the pmpd library, which is a powerful tool for physical modeling, but I suspect there might be a computationally cheaper way to accomplish this task. (which is important for my use case)

    Do I need to break out the dusty old physics calculations & calculate acceleration/velocity/etc., or is there a simpler solution that has a similar effect? Perhaps using [line] is the wrong approach, since it outputs linear ramps… I wonder if I should be polling a value for current velocity with a metro, and then curving the change in velocity towards the new random position via table lookup or some [expr] function?

    Thanks in advance for any thoughts!

    posted in technical issues read more
  • beep.beep

    @th8a Cool! Glad that my past ineptitude led to a teachable moment for the both of us, at least. :computer: :thumbsup:

    posted in technical issues read more
  • beep.beep

    @mod Check out the help documentation for the {text} object. (assuming you're using the newest Pd vanilla)

    [text] has a lot (or perhaps all?) of the same functionality as the older {qlist] object, but there are many more ways of inputting/outputting/loading/saving content. The help doc has subpatches which demonstrate the various functionality. ({text define], [text set], [text sequence], etc.)

    I have seen external libraries which have a lot of sequencer-oriented abstractions, but I haven't personally combed through them enough to know whether there's a simpler solution for your use case.

    posted in technical issues read more
  • beep.beep

    @th8a I had this happen twice in the past... in my case the culprits were:

    1. a message box in a forgotten subpatch which was collecting midi note numbers for later use, using |add2 $1( with no |set( message to clear it. It would eventually grow so large that I would get audio dropouts.

    2. list-lifo & list-fifo, again collecting midi note information but neglecting to clear it every once in a while.

    I suppose some of the specific midi objects could be the problem in your case, for example if an object is expecting note offs but not getting them? (I sometimes get these warnings using maxlib/chord) If that turns out to be the problem, maybe cyclone/flush could help by providing the missing note off messages?

    posted in technical issues read more
  • beep.beep

    @Gabriel-Lecup
    Fascinating! You're correct, it looks like tabread4~~ is included in the zexy library (which is why you can load it in Pd-extended), but it doesn't show up in the Pd help browser for zexy since there is no help patch. (this solves an old mystery for me, as I couldn't figure out how tabread4~~ was the only iem_dp object I could get working, before successfully compiling the rest of the library)

    But indeed, that seems like a strange object to include on its own without the other double precision math objects. Maybe there's a simpler way to implement the dp looper that I'm not seeing, but perhaps more likely that tabread4~~ was included in zexy for a different use that didn't need phasor~~ et al.

    Not sure whether it'll work for you, but here is the version of iem_dp that I compiled for Mac if you'd like to give it a try:
    iem_dp.zip
    ***I'm running the latest Mac OS 10.13.4, Pd 0.48-1 64-bit, not sure if it will work on older OSes or 32-bit Pd.

    If I'm not mistaken, Pd-extended is 32-bit, and also no longer in active development... I would highly recommend migrating to the newest Pd vanilla. Deken makes installing most external libraries easy (which it sounds like you already know how to do), and then you can manually copy iem_dp to your externals directory (in my case, ~/Library/Pd). Be sure to add iem_dp to "Pd libraries to load on startup" in the Pd>Preferences>Startup... menu, then restart Pd to see if it loads for you. (the console will print "iem_dp (R-1.19) library loaded!")

    posted in technical issues read more
  • beep.beep

    Hi GL,

    I spent a good 2 solid weeks beating my head against this very issue recently, as I had the same wishlist as you mentioned (variable speed/direction, long buffers with no artifacts, click-free looping). I tried my hand at adapting B.16.long-varispeed.pd, but I couldn't make it work for dramatic speed changes.

    My solution was indeed to use tabread4~~ from the iem_dp library. (which, to my knowledge, is not on deken... I had to download it from github & compile from source... here's my post from a while back on the subject)

    My looper seems to work, although honestly I'm not sure why—I'd think that the weak link in this case is the precision of the number of samples output by soundfiler, if a very large file is loaded into the table (which can indeed be large if the -maxsize flag is used). I did use the double precision math objects to calculate phasor~~ frequency and tabread~~ read position, but as you can see, the rightmost (dp) inlets/outlets aren't being put to use for most of them. But, nonetheless, it seems clean to my ear!

    The windowing to prevent clicks is adjustable, and is in the {pd window} subpatch. I think I read of that idea on this forum, but I can't remember where... apologies to whomever suggested this great idea. I also added some calculations to adjust the window based on current speed of the playback.

    double_precision_looper.pd (requires iem_dp library)

    dplooper.jpeg
    looperwindow.jpeg
    If you have a more elegant solution/modification to put those math objects to better use, I'd love to see! I'm also crossing my fingers that someday the developers will decide to take the plunge & go full double precision natively in Pd, but I understand the headaches they're faced with in trying to ensure (most/some/any) backwards compatibility with older externals.

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!