• zigmhount

    Hi all (and probably most relevant to @jancsika),
    I noticed today that Purr-data 2.13.0 systematically crashes when I try to save a patch with an [mknob] in it. Counts for patches that used to work with prior versions, as well as empty patches started from nothing with only a [moonlib/mknob] in it ("Save as" opens the window, but the actually saving crashes and the .pd file is 0b big). I seem to have the exact same issue on OpenSuse 15.2 and Debian 9.0 with the packages hosted on OBS (the Opensuse one says

    $ > purr-data -version
    Pd-L2Ork version 2.13.0 (20200802-rev.70066071)
    compiled 12:00:00 Aug 24 2019
    

    Not sure if it is a real bug that I should have reported to Purr-data's Gitlab page, if it is known already,or if I should use another knob or anything?

    posted in technical issues read more
  • zigmhount

    @beep.beep Thanks so much! I will look into all that and test and implement stuff, and I'll come back here if I have more questions!

    posted in technical issues read more
  • zigmhount

    @Tombot7 Thanks so much, very interesting. My looper's approach is however very (very) different from yours, since I took inspiration from midi loopers such as Seq64 or "matrix-based" (not sure what the proper term may be) audio loopers like Luppp, launching the clips with a midi controller with the same matrix of 8*8 buttons. So far using only audio input (from mic or [fluid~]) but I plan to include some MIDI sequencing at some point, at least for CC automation.
    My first attempt included graphical visualization of the waveform and resizing of the array, but I quickly gave it up!
    Interesting considerations about tabplay vs tabread4 and line~ vs. phasor~, I'll just trust you and implement this right away :). I figured that tabread4~ may be handy in case of changing the tempo after recording arrays, but I guess that's something one may not even want to design for on modest hardware.
    Thinking about it, I should probably consider removing [fluid~] from my main dsp patch and put it into a [pd~] subpatch, or (if it makes any difference?) yet another separate Pd instance.

    Well well, this thread is giving me enough work to fill another Covid lockdown - I'm in Spain :sweat_smile:

    posted in technical issues read more
  • zigmhount

    @beep.beep Very useful, thanks again! Note that some of the glitches I hear (like the one I mentioned with the emoji window) can be heard also when Pd is not running at all, so while I'm certain that a higher delay will help, the root cause is somewhere else :) I will try.

    Good advice on the discontinuities. I was kind of hoping that [phasor~] would handle this better than restarting [line~] from 1 to 0, but I suppose that it also just jump from 1 to 0? I've seen other discussion threads about windowing, involving for example interpolation between the end of the array and its start when beginning a new ramp with [line~], but I'll probably have to quite some time to get this to behave properly.

    More questions though :) :
    In your example, you record the ramp up and ramp down into the array itself, right? Is that not audible when looping the same array over and over? Thanks to this ramp in the array, I guess that [tabread4~] may not click even if started without a volume ramp in, would it?

    posted in technical issues read more
  • zigmhount

    Haha, sure, with pleasure to join forces @Tombot7 ! Not sure what the best way to communicate may be - I'll definitely be back on this forum if you post something, and I have a github repo with the latest more or less usable code.
    Latency is not a very big deal for me however since I start playing the tracks as per the main metronome's beat, and I'm not overdubbing :) but I'm interested to see what you've got anyway!

    posted in technical issues read more
  • zigmhount

    @beep.beep I actually haven't seen [pd~] before, thanks again! Since DSP needs to be running, I'm not sure how I can actually use it (if I had my 64 tracks as [pd~] subprocesses, they would all have to be "DSP on"), but I'll keep it in mind. It might be more efficient than OSC messages between several DSP instances of Pd, but my machine only has 2 cores anyway, so I'm not sure whether there is much more to optimize there (for now - at some point I might very well be using my patch on other computers, and other people may use it).

    I'm now in the process of implementing [switch~] in the different subpatches of my track abstraction, so as to shut off [tabwrite~] when playing and shutting off [tabread4~] while recording, let's see how this goes.

    In general, I still hear quite many clicks and glitches when playing, when the [phasor~] reaches 1 and jumps to 0, or just randomly in the middle, even when the DSP instance runs in -nogui, without debug or verbose and without printing OSC messages. Increasing the number of frames per period in Jack from 128 to 1024 doesn't really help. Not sure whether this can be a problem of CPU power or sound card, I may try on another computer to figure it out - I'm on a 10-year old laptop using the embedded sound card :expressionless: (funny thing, I also hear tons of clicks and glitches when opening the emoji panel to write this message, so I suppose it really is a hardware shortfall).

    posted in technical issues read more
  • zigmhount

    All right, for reference, I read some explanations here (2.4.4) but not easy to get it to work without an example, and finally the answer to my main question in this thread: just send [1( or [0( to [switch~] (no argument) to activate or deactivate DSP in this window and all sub-windows (this is weirdly the first time I hear of objects that work for the window rather than the patch or abstraction).

    I have just implemented it and my abstractions do [throw~] the outgoing sig[nal, and now the CPU load is down from 30% to 7-8% when no track is playing!!! Amazing !! Thanks so much @beep.beep!

    Major trouble I've had, for whoever might read this in the future: [switch~] should not be in a subpatch of the abstraction, but in the highest-level window it should act on.

    Cheers!

    posted in technical issues read more
  • zigmhount

    Thanks so much @beep.beep, that sounds like exactly what I need!
    The help documentation about [switch~] is very concise to say the least, but I'll try to figure it out!

    posted in technical issues read more
  • zigmhount

    Hello there,
    I started developing a sampler/looper with Purr Data a couple of months ago (and I've used this forum a lot!), to be used with a 8*8 MIDI launcher. In order to avoid audio drop-out and glitches, I spent the past 2 weeks separating the UI and DSP patches, communicating via OSC (so the UI can be launched with -nrt and -noaudio while DSP is using -rt -jack -nogui) (I'm on Debian 9.0).
    To avoid dynamic patching and array creation, I then have 64 instances of the track's DSP abstraction, waiting for the UI to use them, even if only 3 or 4 tracks are actually used.
    I find however that the idle DSP instance of Pd - all tracks' abstractions loaded, but not recording or playing any audio - uses 28-29% of my CPU when monitoring with Pd's load meter, while the idle UI instance uses only 5% (I'm on an old machine, but still). I have narrowed it down to the tracks abstractions, since I get only 5% CPU use (DSP side) when there is only one idle track patch instead of 64.
    Looking deeper into it, I find that if I delete the 2 [tabread4~] objects (each track has 2 arrays for stereo) I significantly reduce the CPU load, from ~28% to ~17% with 64 idle patches. 17% is still significant, but I couldn't identify any other object with such an important impact.

    Is it known that [tabread4~] (tabread~ does no better) uses significant CPU even if idle, both with a phasor~ at 0Hz or not connected at all to the phasor~? Is there a way to make it "sleep" completely? or is there no/little risk of audio drop-out if I create that tabread4~ object dynamically once I actually need the track?
    The CPU load increases too ~40% when I turn DSP off, I guess because of errors or confused messages with empty arguments when processing audio signals.

    Any other advice to reduce the CPU load is of course also welcome :)
    Thank you!

    posted in technical issues read more
  • zigmhount

    Hello!
    I've just started using Purr Data today, and I've ran several times into the very same bug.
    I'm using Pd-L2Ork version 2.10.1 (20200311-rev.501d8b2b) on Debian 9 (installed via the deb packages available on OBS). Shall I try with a different version?

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!