rezer~ (looper w/ sample-accuracy)-now beta-testing(ends 9/12/2019)


    May 11 2019 | 8:33 pm
    [Latest News: MAJOR UPDATE! - v.008 - released May 15th, 2019 ] Hello and a beautiful day to you all! πŸ€— (after stepping away from Max for 2 years due to life stuff a few years back, didn't think i'd get my chops back, but lately seems perhaps improving... so this is quite a lucky thing that i created this... hope you'll all be patient with me as this work was very unexpected and flowed out of me as though from somewhere else...)
    feature list:
    • it's free πŸ˜‹
    • sample-accurate stopping/starting/retriggering
    • built-in de-clicking fades at all starts, stops, loop-points, and retriggers(as well as when play and record positions cross; at loop-points and retriggers, the de-clicking is a tight crossfade from where the playback was into where the playback skips to), plus the same on the recording end(with a clever bit added to incorporate fading/crossfading previously-recorded material around an overdub amount)
    • different modes for styles of sequencing(things can be triggered right away, or they can wait til a loop-point is crossed before responding to signal changes/triggers at inlets)
    • can only do 1x or -1x recording speed - this leaves the object much easier to use efficiently CPU-wise as well as manage ongoing development(but years down the line, if you're still craving this object with varispeed recording, let me know, i'll think about it then...)
    • playback employs 'hermetic bicubic'(also just known as a form of 'cubic') interpolation at all times for high-quality varispeed playback, and the interface allows you to control the record-head separately from the playhead(each has their own independent start/stop, loop-start/end signal-inlets for specific control).... (this also means there is an additional de-clicking to take care of whenever the playhead crosses the recordhead; it will duck out the playhead smoothly momentarily until they are safely apart from each other(at a distance of 'fade' * 2))
    • additional 'virtual' playback boundaries - so you can limit playback controls to one part of a buffer~ while recording can go all over
    • 'overdub' amount(for recording) is controlled by signal - allows for side-chain driven modulation or precise mixing
    • helpfile shows how to make it MC-compatible - so you can have as many playheads and recordheads all independently controlled as you'd like πŸ˜ƒ
    • currently only 'mono' and 'stereo' modes available - the way mono/stereo works is you have to instantiate the object with a 2nd argument for the type you want and then the object will always only play/record in that channel-setup.. for example, a rezer~ instantiated as "rezer~ bufname 1" is only capable of addressing mono-buffer~s, and you can't send a message to it to suddenly change it to address stereo buffer~s; if you want to switch between stereo and mono buffer~s, use a stereo form of rezer~(no 2nd argument defaults to stereo, so just instantiate like so: "rezer~ bufname") and then create your own switching mechanism at the output of rezer~ to send the left channel out to both channels when the buffer~ is mono
    Everything you need(both pc and mac) attached here, the helpfile will tell you much more... however, it's not the best help-file πŸ˜‚ ...it's actually the patches i used for testing(when testing for de-clicking, writing low/bassy sine tones really fast into a buffer~ is a very good test 😁), so feel free to make patches which you think could demonstrate things better and maybe we can add them as tabs to the helpfile. If you want a quick demo, go to the 'xtra' tab and just turn on audio, click the toggle on near the top-left, and then listen and watch(it will fill the buffer~, mix with overdub from 3 different sources, and playback with sample-accurate rhythmic accuracy in mode 1(changes aren't registered til end of loops)). Sounds like a perpetual remix machine πŸ˜„
    Some notes on possible areas of confusion:
    • The first most likely area of confusion for people: to retrigger, you simply send a different 'Starting Phase/Index', the difference in signal value at that inlet causes the object to jump to the new position(loop window is carried with it)... In addition, alternating positive and negative values of the same number is the way to retrigger the object quickly from the same starting point(example: say i want to quickly repeat-retrigger from the point exactly halfway in the buffer~, i need to set up the patch so that each alternate hit will send the opposite sign of that value in a signal like so: 0.5..... -0.5.....0.5 etc.), to retrigger the starting point of 0. you can alternate between 0. and 1.(in the opening tab of the help-file, the toggle labelled "RetriggerNumBox" does this, there are probably better ways to setup that interface but that's one easy way)
    • there is no speed inlet for recording(use the recording's on/off inlet, 1 for forward record, -1 for reverse record, and 0 for off.... that reminds me, there may be a possible click if you suddenly go from 1 to -1 for recording direction, keep me informed on what you find and i might look into trying to de-click that further for you)
    • "what's happening with karma~?" - karma~ is Rodrigo's baby(his design) and so he's leading that into deeper territory, will leave it to him to inform you further about that, but rest assured it's still around and very much alive(i was having too much trouble returning to that level of complexity in terms of coding/development, i didn't expect to even get this much done on 'rezer~' but because this all flowed out of me in 2 weeks i am able to put it out now and it's likely i'll take a step back from all this for a bit now again too...).... rezer~ and karma~ can coexist nicely in the same ecosystem(each shines at different things)
    TRULY SORRY FOR THE ULTRA-LONG POST! Let me know any questions you have here on this thread, I'll do my best to keep up and keep trying to fix and improve things here, and I hope you all enjoy it immensely. Thanks for reading or checking this out πŸ™ ALL ATTACHED HERE(.mxo file is for mac, .mxe64 file is for windows... both are 64-bit only):
    MOST CURRENT VERSION - V.008 - released May 14th, 2019:
    Also, i started a github just for the C code(anyone trying to create similar in gen~ can use this) here. 🍻

    • May 12 2019 | 9:53 am
      Thanks Raja - your work on Karma was legendary, and this has the features I've been really keen to get. Greatly appreciate your sharing this.
    • May 12 2019 | 1:23 pm
      Super!<3
    • May 13 2019 | 12:07 pm
      Great! Thanks! So is karma~ considered obsolete?
    • May 13 2019 | 2:49 pm
      Awesome!
      Looking forward to having a good play with this. That's one of the biggest things people will message me about for karma~, is how to sync up multiple instances.
      @Alfonso karma~ is still going (there's a v1.5 on github that isn't terribly well documented yet), with some nice plans for a 2.0 build in the future.
    • May 15 2019 | 7:07 am
      MAJOR UPDATE! - v.008 - released May 15th, 2019 (it's the 2nd/last attachment to the top/original post, you'll see it labelled 'v008' - again, the .mxo for Mac, the .mxe64 for PC, plus a new helpfile - all attached there)
      For a more easy experience getting it to work like karma~ where you can use the recording length to set the window duration, i've added a "Mode 3"! The helpfile tab 'mode3' will show you how this is done(in addition will show you how to append using mode 0). Detailed list:
      • Added mode3 for setting playback duration by recording length
      • optimized interpolation(whole number speeds don't need interpolation so it's skipped in such cases)
      • forced inline functions(a small compiler-specific consideration, not a huge difference, but just in case it helps optimize further)
      • removed some unnecessary constraints
      • extra code for varying buffer~ sample-rates
      • removed unnecessary things like unused messages, etc.
      • added safer checks for reworking buffer~-access boundaries whenever 't_max_err' notifications are received/requested upon buffer~-modifications made by sources outside the external
      • reworked boundaries/constraints.
      • updated Github with the v.008 code
      • created another tab to explain mode 3 in the helpfile
      • some known issues:
        1. there's a possible crash if you leave rezer~ with playback or recording on while rapidly resizing the buffer~ it's referring to(i generally get this crash if i attempt to constantly switch the files in the buffer~ at a constant rate and more rapidly than once every 100ms, while i am recording/playing in a later part of a bigger buffer~ and suddenly replace the buffer~'s file with a shorter file thus resizing it much smaller, leaving playback/recording in a dangerous area), to avoid the crash altogether, you can turn off playback and recording temporarily for a short instant before you resize-buffer~/load-another-file, and then turn it back on after the resizing/loading is completed
      This will be the last major push for awhile, and because there is so much here now, i can't say i've thoroughly tested it all, so have a go, and enjoy. πŸ‘Š
      Thanks, All! I truly appreciate everyone checking it out so farπŸ™
      [Edit: @Alfonso - karma~ is still alive, these two objects will serve different purposes in different ways and exist nicely in the same ecosystem πŸ‘]
    • Jun 30 2019 | 5:14 am
    • Jun 30 2019 | 8:33 am
      "control the record-head separately from the playhead"!!!