• mnb

    groovebox2 (the groovebox2b example) has a load of about 23 percent on my 3.2 ghz haswell i5 using integrated gfx. depending on the fx selected. i can load 6 instances of this patch before i get audio-dropouts (at about 95 percent cpu-load)

    while there is probably not much that can be done regarding the gui (it is updated at 1/16 step rate), it should be possible to save cpu by replacing the bandlimited oscillators with simpler ones, and using less, or different fx.
    (the xy-one uses quite a lot cpu) and maybe using a simpler reverb. and of course using multithreading/pd~
    which would require a bit of work though...

    posted in technical issues read more
  • mnb

    i suppose you are using the 1st groovebox (groovebox1r4)? it uses filters based on fexpr~ which are very demanding, you could try to replace these wirh other filters (pole/zero based, or even vcf~). another problem is the large gui with many elements. you can try to avoid gui redraws as much as possible. or you could try to build something friendlier (cpu-wise) using my modular groovebox2.

    posted in technical issues read more
  • mnb

    "Every single cycle wavform is made of 2048 points"

    tabread4~ needs 3 points more. (see tabread4~ help-patch)

    posted in technical issues read more
  • mnb

    probably the right outlet of vcf~

    posted in technical issues read more
  • mnb

    it is probably too much for the rpi, at least for the rpi1. to throw out the oversampling, you can remove the block object in all 7 "stps_oscs", and all objects between the vcf-out and the outlet (connect the vcf right lowpass out directly to the outlet). i believe that should suffice even for the rpi1. if not, you could try to replace the rev3 with a cheaper reverb...

    posted in technical issues read more
  • mnb

    and i'm not exactly sure if the 'classic mandelbrot-set series' yields any musically interesting results, but
    i am quite sure that it only produces usable results for carefully chosen values of c (on the border of the mandelbrot set where it neither converges nor diverges, at least not so quick...).

    maybe simple real-valued recursive functions are more fun. the idea is to blow up a value (multiplying, adding constants, whatever), then wrap it to a range, and feed it to the next iteration. like the classic gingerbreadman, hopalong etc. fractals. linke in the attached example. fractalmelody.pd

    posted in technical issues read more
  • mnb

    i don't understand why the iterations are 'hardcoded'. wouldn't it be simpler to just send the output of the expr to its input (via [float] and bang (and maybe [until]) and shouldn't the numbers be complex ones? that would be something like next_zr=(zr * zr) - (zi * zi) + cr and next_zi=2 * zr * zi + ci for the typical mandelbrot set series. (afair...)

    posted in technical issues read more
  • mnb

    it looks like this is caused by certain 2d operations not supported (accelerated) by the graphics-card driver.
    this happens here with the opensource radeon driver, as well as on a mac-mini (running ubuntu)
    with the nouveau driver.
    it is worse, the larger the window is.
    proprietary fglrx runs fine (concerning this issue...), opensource intel too.

    posted in technical issues read more
  • mnb

    you can use 'add' and 'add2' (many of these) to add messages to a qlist. i have made a little
    recorder/player using qlists, it is in my instrument-collection at my homepage.

    posted in technical issues read more
  • mnb

    you dont have to use shell or something like that in extended, there is filesize, or fsize, which outputs the size of a file in bytes. if you know the samplerate, bit-depth
    and header-size, it is easy to calculate the length of the audiofile.

    if you want audio in tables (without dropouts while loading big files),
    you can use readsf~ in a reblocked subpatch, http://puredata.hurleur.com/viewtopic.php?pid=5387#p5387
    and you could split huge audiofiles into multiple tables, to avoid the problems with float precision. but i dont think its worth the effort.

    posted in technical issues read more
  • mnb

    a (not very elegant) solution in pd vanilla could be the
    use of 2 readsf~ objects, the 2nd with an offset which has the length of
    the transition. when the 2nd readsf reaches the end, it is time to crossfade.

    and there might be an object in extended to get the filesize without loading
    the entire audio into in array. (system? shell?)

    posted in technical issues read more
  • mnb

    fexpr-filters need an insane amount of cpu. cpole~/czero~ based ones are much
    more efficient. examples of how to get the pole/zero positions
    from coefficients can be found in the rj-lib, mmb-master (biquad)
    and in my own instruments.

    the other output of vcf~ is also a lowpass.

    posted in technical issues read more
  • mnb

    you are probably recording the note-off velocity, which
    should b 0. you could use [moses] to filter the 0s.

    if you have a given tempo and a fixed (maximum) length,
    recording to tables is fine. otherwise, if you want to use midi
    more like an audio looper, you could assemble messages from
    your recorded midi-notes, and use a qlist for playback.
    (i have done this in my qlist-recorder). not that well suited for
    recording twenty minutes of knob twiddling, but works
    fine for shorter sequences.

    posted in technical issues read more
  • mnb

    metros can take float values as tempo, and are (i think at least)
    sample-accurate. a [metro 500] and [metro 500.333] start to drift,
    two [metro 500.333] not. it can not go faster than 1 ms though.

    you could also use [bang~] and do your calculations at samplerate
    or below. (within blocks >=64 samples though...)

    posted in technical issues read more
  • mnb

    just a few things:
    there are no (not the usual) 'types' in pd, just numbers.
    'int' is just a rounded (truncated) 'float', and thus [t i b] gives an error-message,
    and outputs a float anyway. use [t f b] instead.
    dont even try to format comments ;). (or use a new comment object, if you
    really need a manual line-break.)
    for globals which you need in several subpatches, you could use
    and [r foo] as 'wireless connections'. and if you do not want to
    detect a range, but a specific (int) nr, you can use a
    [select 0 1 2 3...] instead of a "[moses]-cascade" (like in makechord)

    posted in technical issues read more
  • mnb

    there is/was a pd-vst plugin: http://puredata.info/downloads/pdvst
    i think the pd version used there is rather outdated, an it was quite difficult to
    use/install and only worked as a vst instrument or effect, i don't remember which.

    with libpd though, it should be quite easy to make a pd-vst plugin, and
    i wonder why this (apparently) has not happened yet.

    update: i was wrong here. it is not (yet) easy to make a vst plugin with libpd, since it can not use multiple instances. it might be possible to make a plugin as a kind of bridge, communicating with an instance of pd running seperately, but that is
    probably far from 'easy'...

    posted in technical issues read more
  • mnb

    i use tabplay~ with 88 tables and about 250 mb samples
    of piano sounds and 24 voices without any problems.
    (it takes about 3 seconds to load though). the cpu load is
    hardly noticeable. i suspect the pitchshift is more likely the reason
    for any overload, or perhaps very low memory, on a mobile
    device for example. (pd stores all sample as 32 bit float
    internally)

    playing with readsf~ should work, but it might be necessary to
    preload the beginnings of the samples into memory,
    and crossfade after the first 64 ms or so. this might be worth the
    effort if you want to quickly switch between sounds in a huge library,
    without any interruptions of audio output.

    posted in technical issues read more
  • mnb

    this kind of pianoroll is rather easy to make: basically use some (16, 32,whatever)
    vradios and connect these to [float]s or [tabwrites], and use a counter and a select to play the stored float values, or a table and a counter + tabread
    (like in the video). you could also use a table/array directly,
    or sliders instead of vradios. you can change the line thickness in an array
    to 3 pixel, but afaik only by using an text editor to change the last nr in the
    #x coords... line to 1. for more sophisticated sequencers i would recommend data structures. there is a 'proof of concept'-pinaoroll on my website.

    posted in technical issues read more
  • mnb

    that is right, but you can do whatever you like (64->until,...) on the 64sample
    (or bigger) buffer you get at bang~.

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!