Playtime 2 - Early Access - Feedback

[helgoboss]

Hi Playtime 2 early access users,

feel free to give Playtime 2 early-access-related feedback here. Alternatively, you can respond to me directly by email.

Benjamin

[andy79ro]

Hi Benjamin,

I'm impressed and looking forward to the commercial release. Congrats!
In short:

• in the upper right corner I see helgobox 0.2.0, eventhough in the reapack extension it shows 2.16.0. Am i checking the right version? Hope so.
• 1. Matrix sequencer and arrangement writing - it works beautifully
• 2. Ad-hoc MIDI mappings - after pressing the right corner to become red, it does not seem to record/assign a midi press afterwards. Possibly my fault, not knowing how to use
• 3. Different trigger play modes - Momentary does not seem to work as intended. Overall, use of ignited clips not clear. I can only make them become ignited when using the silence hand. And then I see that the play ignited plays them.
• 4. Smart record button - seems to work as intended
• 5. Better support for quantizations > 1 bar - seems to be working. I see the concentric circle appearing

I know you don't want bug reports but this hinders the ability to test features:

• almost always notes hang at clip end, and none of the stop buttons work on it except the Reaper transport stop
• the Scene play buttons (first column) don't work

Merry Christmas!

Arpad

[helgoboss]

✅ (all of the mentioned issues should be fixed since at least 2.16.0-pre.13)

[helgoboss]

Hi Benjamin,

I'm impressed and looking forward to the commercial release. Congrats! In short:

• in the upper right corner I see helgobox 0.2.0, eventhough in the reapack extension it shows 2.16.0. Am i checking the right version? Hope so.

Yes, it's the correct version. App and plug-in have different versions. I guess I shouldn't display the app version so prominently, otherwise it's confusing. Noted.

• 1. Matrix sequencer and arrangement writing - it works beautifully
• 2. Ad-hoc MIDI mappings - after pressing the right corner to become red, it does not seem to record/assign a midi press afterwards. Possibly my fault, not knowing how to use

It might need some initial setup on the ReaLearn side because it's powered by that (all it does is create ReaLearn mappings): Either choose input and arm the track. Or choose a ReaLearn hardware input. Does it work then? Good point, not super intuitive.

• 3. Different trigger play modes - Momentary does not seem to work as intended. Overall, use of ignited clips not clear. I can only make them become ignited when using the silence hand. And then I see that the play ignited plays them.

What's your observation with momentary?

Clips are supposed to ignite when double-clicking the matrix or column stop button (and the silence hand). Double-clicking the matrix stop button again should clear all ignited clips. Does it behave that way / what was your expectation?

• 4. Smart record button - seems to work as intended
• 5. Better support for quantizations > 1 bar - seems to be working. I see the concentric circle appearing

I know you don't want bug reports but this hinders the ability to test features:

• almost always notes hang at clip end, and none of the stop buttons work on it except the Reaper transport stop

I hope to fix this in the next milestone. There's hardly anything as annoying as hanging notes ;)

• the Scene play buttons (first column) don't work

Oops, you are right. It's because the columns have wrong default values now ... both "exclusive mode" and "follow scenes" should be checked by default. Fixing. You can workaround this by manually checking them.

[helgoboss]

✅ (all of the mentioned issues should be fixed since at least 2.16.0-pre.13)

[Trekopep]

Hi there! This is all looking great!

Haven't had too much time to look into it yet, but am I correct that at the moment, the ad-hoc MIDI mappings can only be used to play/stop recordings, not to make new recordings or do similar things? (My use-case is live looping during improv)

Also, a couple things that are making it hard to test:

• Currently I can't make use of the "Track audio output" option, because anything recorded via there plays back with a bitcrushed/distorted sound on top of it. I created a new project, just to be sure it wasn't a result of any effects or specific VSTs.
• Not as important, but the metronome doesn't produce any tap sound, and instead adds a similar bitcrushed effect to whatever I play.

[seantypedthis]

Same for me with "Track audio output", using ASIO drivers on Windows 10 x64 in REAPER v7.09.
Also happens when using virtual audio cable to the "Track Input" source to loopback from another track in stereo. However, when I record to a Column slot via virtual audio cable in mono, the playback comes out clean. Might have something to do with recording and playing back stereo audio, as REAPERS default sends/outputs are in pairs...

Doing my best not to bug report, I swear!

[helgoboss]

Yes, definitely something weird going on there. As soon as the next milestone is out (which is mainly about grid controller integration), I will have a look what causes this.

[helgoboss]

✅ (all of the mentioned issues should be fixed since at least 2.16.0-pre.13, except recording from "Track audio output" feature which has been postponed)

[helgoboss]

Hi there! This is all looking great!

Haven't had too much time to look into it yet, but am I correct that at the moment, the ad-hoc MIDI mappings can only be used to play/stop recordings, not to make new recordings or do similar things? (My use-case is live looping during improv)

Correct. I'm thinking about integrating it by adding a new global "MIDI trigger mode" option that's provides all options of the normal trigger modes (toggle, retrigger, momentary) but also optional recording in case the column track is armed. The reason why I don't want to enable this by default is that it might cause accidental recording. BTW, you could use ReaLearn directly to assign buttons to e.g. just "Record clip" (ATM via Lua only). Such advanced mappings are possible via ReaLearn but I don't want to support them for the simplified Playtime interface.

Also, a couple things that are making it hard to test:

• Currently I can't make use of the "Track audio output" option, because anything recorded via there plays back with a bitcrushed/distorted sound on top of it. I created a new project, just to be sure it wasn't a result of any effects or specific VSTs.
• Not as important, but the metronome doesn't produce any tap sound, and instead adds a similar bitcrushed effect to whatever I play.

Is it possible you are using WASAPI driver? I have to investigate it, it makes exactly this kind of issues.

[helgoboss]

✅

[Trekopep]

BTW, you could use ReaLearn directly to assign buttons to e.g. just "Record clip" (ATM via Lua only). Such advanced mappings are possible via ReaLearn but I don't want to support them for the simplified Playtime interface.

Makes sense to me!

Is it possible you are using WASAPI driver? I have to investigate it, it makes exactly this kind of issues.

Nope, I'm using a Focusrite USB ASIO Driver (Scarlett Solo 3rd Gen, in case that's helpful). Windows 10, Reaper v6.83

[helgoboss]

✅

[vonglan]

I am trying Playtime 2 with the APC20 presets that I built last year, based on the APC Key 25 example project / Lua scripts.
It works quite well.
However, the pad colors on the APC20 don't distinguish between empty and filled slots any more. I only get yellow ("stopped"), green ("playing") and off ("empty") colors.
Did the state ids change? (e.g. "empty", "scheduled_for_record_start"...)?
Do you have and can you provide your current APC Key 25 Lua scripts?

[helgoboss]

It's possible that something changed about that, not sure. I'm working on the general controller integration right now, not yet on specific controllers, so there's no updated script yet.

[helgoboss]

I'm now starting to work on the actual controller preset. The effect that you are seeing is due to a change within the Clip Engine, so an updated preset won't help. Fixed it locally already but it will still take about two weeks for the next milestone to be released.

[helgoboss]

✅ (all of the mentioned issues should be fixed since at least 2.16.0-pre.13)

[vonglan]

Where can I set the recording settings (e.g. record stop time)? I think I saw them in the Inspector window once, but can't recall how I got there.

[helgoboss]

Click the "Main" cell (top-left of the matrix)

[helgoboss]

✅

[seantypedthis]

Just from the first day or two with Helgobox, super intuitive, really fun to use and functions very cleanly at it's core use case!

General Feedback

• I like how it pre-fabricates all of the track routing/sends when you create a new column. That the application can mirror and manipulate the state of the track in the TCP is really useful.

• Drag and drop works really well. I've dropped files (including video) from Windows explorer, the REAPER media explorer, and Rolling Sampler without a hitch, things run in sync right away. I did run into some hiccups when the tracks were not record armed, but I'd have to test with that more.

• I really enjoy the UI, I can tell a lot of thought and work went into it, and it made jumping in very very easy/accesible. I can't wait until there is a REAPER dockable iteration! I do like how it obeys window snapping in Windows, though.

• I also appreciate the widget in the upper right that allows you to hide and show parts of the application that you may or may not be using, a really good way to streamline/decluter for more performance oriented views.

• The Realearn backend for ad-hoc MIDI mapping is very useful, especially if you've been using Realearn for a while. I like that the mapping is exposed to somewhere that is viewable and tweakable as opposed to Playtime 1, which was fairly in box, or requiring going through the JSON. Can't wait to try it out when record modes are available in Realearn!

Couple of usability things

• One caveat that might warrant a hint/documentation: In REAPER, Track preferences "send audio by default" and "Send gain" must be set for "Track audio output" recording option to work properly, otherwise you'll get silence. Took me a minute to figure out, so be weary if those settings are modified from default.

• Also, record arm by default might be a good idea, as many functions seem reliant on it(?)

Some initial thoughts on feature request

• Reverse clip option, pitch shift (probably implemented with resample modes?). Will Helgobox interpret MIDI, audio and video as REAPER items, or is it your own implementation? Will the clips have access to REAPER actions/manipulation, like Playtime 1? I think simplification is good, but there might be a few actions, such as reverse, that I would like to see make the transition to Helgobox ( reverse really helps when you still want to do something creative with a poorly timed loop, haha).

• Trigger modes on a per column basis would be useful, some tracks could be loops, some one shots, note on/off, momentary, etc...thinking about it, some feature request start to resemble a sampler more than clip launcher, so maybe that's a question of scope.

That's it for now, hope to have more time in the coming week to really get into things. Thanks again for all the thought, hardwork, and engagement around your creations!

[seantypedthis]

Same, can also reproduce with fresh project with no plugins. The example video is a new project with a fresh instance of Playtime using a blank audio template (I really do appreciate that fabrication system, by the way!) that I dropped a single wav file into, PDC reads 0/0, no fx on the master track.
No big deal, I usually keep rec arm off by default so REAPER doesn't use the tiny cpu time on an empty track after creation, easier to keep track of cpu usage on my end. However, it makes sense for me to have the tracks in Playtime armed by default (or have the option to) if your purpose is to feed them live input.
It also occurs to me that is more of how I set my default REAPER settings, not a setting Playtime needs to control. I might just turn that option back on to rec arm by default in the REAPER settings, as I'm sure I made a lot of these settings with older hardware and different use cases in mind. Good way to do some house keeping!

[helgoboss]

@seantypedthis Got finally some time to look into this "record-arm glitch". This is definitely a bug and it's something that should work without the track being armed. For playback, it's not supposed to make any difference whether the track is armed or not. If it makes a difference, it's a bug ;)

✅ (just marking this as "read", I took note of the "record-arm glitch" and will attempt to fix it for the next version)

[seantypedthis]

It's probably related to PDC.

I was just about to report a bug when I remembered this comment.

If I disable a plugin that introduces PDC on a Playtime track with a clip playing, this same glitch/bug occurs, even if the track is record armed. Other plugins with no reported PDC disable and reenable fine with no glitching.
A work around seems to be to set the track's "Chain PDC mode" to "Ignore plug-in delay." Record arm must still remain enabled, though.

But good heads up on PDC, I'll keep it in mind if I experience any more anomalies.

[helgoboss]

@seantypedthis BTW, I managed to fix the issue you showed in the video.

Someone else reported issues with low buffer sizes, that's fixed as well.

The GUI crash on a user's older non-SSE4 compatible CPU should also be fixed.

vonglan's MIDI timing issue was caused by anticipative FX. Playtime doesn't work with anticipative FX at the moment. Fortunately, it can be disabled per track. Which the next Playtime alpha version will do automatically.

Happy to say: Those were the 4 max showstopper bugs reported so far. And they are fixed, at least on my machine ;) Next week I will squash the rest ... and then it's time for a new alpha release.

[seantypedthis]

Tested with Record Arm off, and happy to say this appears to have been resolved, clips playback nicely even when using REAPER's transport! Great work!

[vonglan]

Already used the new version yesterday, looks good.
Had problems with "out of synch" playback of different clips, but I don't have much experience with Live (or Playtime), so I assume this was due to some usage error on my side.
I noticed there is a new button for "Smart Record". I was always wondering, what is the best way to start and stop recordings without having to move one hand from the keyboard over to the grid controller (in my case an old APC 20). Is "Smart Record" intended for that, i.e. select an empty clip, then press "Smart Record" for starting and stopping the recording? (And being able to map Smart Record to a controller, or the lowest note of the keyboard)

[helgoboss]

Smart record is now mappable. Timing has been improved.

[helgoboss]

✅ (smart record is mappable)

[vonglan]

Just "for the record": Benjamin helped me: the timing glitch I had (noticeable delay when un-arming a track) was due to the following Reaper preference:

• Audio => Buffering => Anticipative FX processing => Allow on tracks with open MIDI editors

[helgoboss]

@vonglan Just a note: In upcoming version, Playtime will take care of this automatically. Not by touching the global preference but by preventing anticipative for each track that it touches. ✅

[vonglan]

tested, works

[Trekopep]

I feel like this is a pretty basic question, but I'm having trouble getting started with my controller. I have a Launchpad X (not a Pro), and when I plug it in it automatically creates a New controller in the Global Controller Settings with LPX MIDI as the input/output and "Launchpad Pro - Playtime" as the Main preset, which makes me think it's at least partly working. However, pressing the pads on my Launchpad doesn't seem to do anything (can't play back a recording I made in col1/row1), and there's no visual feedback on the Launchpad indicating anything has changed.

I wondered if this might be because I need the Launchpad to be in Session/DAW mode, which I needed to do to get it to interact with ReaLearn previously (which, the way I was doing that was by sending a MIDI Feedback output message of "F0 00 20 29 02 0C 10 1 F7" via ReaLearn; not sure if there's a better way to do that that I'm missing), but that doesn't appear to have made a difference.

I also tried using MIDI triggers, but wasn't able to assign those either; pressing pads after clicking to learn a key did nothing.

This is an aside, but is Recording via Launchpad planned to be supported via the ReaLearn UI outside of Luau? And if not, is there somewhere I can find the possible options for Luau? I'm noticing that if I guess incorrectly for a slot, e.g. try "Record" for the "PlaytimeSlotManagementAction" and then paste the Luau, it shows me a list of actual options for that, but I'm assuming there's an easier path than guess and check.

(Sorry for all the questions; I've never used Luau and am honestly still finding my feet on Reaper in many ways too, so I'm struggling a bit)

[helgoboss]

Hi, Launchpad X is not supported yet, only the controllers I specifically mentioned. Interesting that it detected it though, maybe it has a similar device identity to the Launchpad Pro. Oh, and the Launchpad Pro needs to be in Live mode to work.

Recording via controllers doesn't work at the moment, I forgot to mention this on the early access page.

Anyway, the real testing starts with the next milestone. At this point, bugs are still very common.

[helgoboss]

✅ (just marking this as "read", new controllers will be added step by step, modifying mappings via ReaLearn UI is supported now BTW)

[andy79ro]

Hi,
I upgraded as per guidance, all went smooth.
I was hoping that the Launchpad Pro MkIII that I have, would benefit the MkII preset that you prepared. Unfortunately, doesn't seem to be compatible.
On the MkIII the Session button should be activated for the cliplauncher to work as intended. Now it is inactive so only the note view is active, where the buttons corresponding to existing clips in the app, trigger clips and notes too somehow, so it's a bit messy. I understand though that MKIII has rather different implementation.

I see the overdub feature in the menu :) looking forward to it being implemented.

Otherwise, the app works very nicely! Congrats!

[helgoboss]

First: I have no idea how similar/different the MkIII is from the MkII (for sure, Playtime will not auto-detect it). On the MkII, it's currently necessary to enter live mode manually by pressing the upper-left round button + the upper-left grid pad (subject for improvement). Maybe similar on MkIII?

[helgoboss]

✅ (just marking this as "read", new controllers will be added step by step)

[gevialex]

Hi, I just gave the early current release a try (Helgobox V 2.16.0-pre.13). Reaper crashes when I click on "Menu -> Show app" . So far I've tested it with reaper 7.11(release version)installed as portable and reaper7.11dev 0313 also isntalled as portable in a different folder.. In both cases reaper crashes entirely with no error messages or warning when I click on "Menu -> Show app". I'm running windows 10 Pro 64bit. PC is PhenomIIx6-1100 16gb ram, GPU is nvidia GTX960. I'd be happy to provide any other info.

[helgoboss]

Thanks for all of that information, it's really helpful. I will try me best to fix it soon.

[helgoboss]

Good news. This bug has been fixed in the GUI engine that I use. The next pre-release of Helgobox will contain that fix. But that could still take 2 weeks or so.

[gevialex]

That's excellent!, really great news!
Question, for now the app is only run from the same device/ installation as the helgobox is running right?
In the future the app could be ran from a different /portable device such as android?
Thanks!

[helgoboss]

Yes, it's fundamentally made to also run on another machine, that also includes Android or iOS. To be nicely usable on tablets (or even smartphones), the user interface needs a few adjustments though. I tried it on an iPad and some UI elements are just too small. Increasing the overall size in the settings helps already.

[helgoboss]

✅ (just marking this as "read" ... sorry, I see the 2 weeks already passed, trying to make a build with the fix ASAP)

[gevialex]

Thanks for all of that information, it's really helpful. I will try me best to fix it soon.
Thanks! I'm wondering if this could be related to the fact that my cpu only supports up to sse3 and sse4a cpu instructions, it doesnt support ssse3 or sse4.1 or sse4.2. Reaper all in all and playtime1 work perfectly since I have a decent 6 core cpu and 16gb of ram, just a little old though :(

[helgoboss]

Yes, that's exactly the reason. But I think it can be fixed, I will get in contact as soon as I have a fix.

[helgoboss]

✅ (just marking this as "read")

[helgoboss]

@gevialex The new alpha is finally available. I'm very interested to know if it works for you now.

[gevialex]

Looking good and working fine here right now with this last alpha version :) Gui loads well and testing some clips right! Cheers

[vonglan]

I am just finishing adapting the presets for the APC 20.
I have one feature idea for the future:
The APC Key 25 has a "Device" mode to use the knobs to control Ableton Live "Device" (plugin/VST) macros.
Similarly, on the APC20, there are 3 "User 1" to "User 3" modes for the faders.
To use these for controlling VSTs on tracks (columns), I would like to be able to forward a ReaLearn virtual message to a ReaLearn instance on the selected (armed) track.
Example:
APC Key 25, knobs in "Device" mode, knob 1 should control the parameter "Cutoff Frequency" of a VST on the currently armed track (Playtime column), via a virtual Multi (e.g. "SY/Cutoff") that is processed in the Main Preset in the ReaLearn instance of that track. (Optimally, absolute-to-relative would also be supported.)

[helgoboss]

To use these for controlling VSTs on tracks (columns), I would like to be able to forward a ReaLearn virtual message to a ReaLearn instance on the selected (armed) track.

I don't think this use case needs forwarding of virtual messages to other instances. This could be achieved by a central ReaLearn instance (e.g. the same that hosts Playtime). E.g. with "FX parameter: Set value" target, track = "Selected". That way, the "Device mode" support could be part of the same main preset that controls the clip matrix. It's just a lack of time that I haven't already implemented "Device" mode" in such a way.

[vonglan]

That would only work for one specific parameter of a specific VST. But I would like to use the generic SY targets (like filter cutoff, filter resonance), so the "message" arrives no matter which particular VST is used (virtual sourced mapped to VST-specific target).

[helgoboss]

It would work with arbitrary VSTs, either by simply controlling the first n parameters of each VST or by using "auto-load" to load a specific set of mappings for each VST. Or even by using Pot Browser's auto-mapped paraneters, but this is not fleshed out yet.

[vonglan]

If there any other LinnStrument128 users out there: I am trying to build a Playtime/ReaLearn Preset and a "routing JSFX", so the LinnStrument can be used as an "all-in-one" controller for Playtime, like the APC Key 25. Right-hand side to control Playtime (grid etc), left side for playing. Switchable to full surface for playing. (Not sure how that works out with the full surface, because I still want to start recording for an arbitrary slot with one special button - See my comment from Feb 9 above.)

[seantypedthis]

To this point in the changelog:

Improved usability by preventing Playtime from being used from the monitoring FX chain (which would not work as expected in some cases)

Does this mean that you can not use any instances of Helgobox/Realearn in monitoring FX while using Playtime?
It would seem that the first instance of Helgobox in my monitoring fx chain conflicts with Playtime. When I try to open the mapping in Realearn by clicking the "Show Helgobox Plug-in" button, it won't open the instance used to start the app, but rather the first instance of Realearn in my monitoring fx chain.

[helgoboss]

You can still use Helgobox/ReaLearn instances on the monitoring FX chain. You just can't use Playtime (= create a Playtime Clip Matrix) within such an instance.

If "Show/hide Playtime" action (= the Playtime button in the toolbar) opens an FX in the montoring FX chain, then that would be a bug. Are you talking about that action? I'll have a look.

[helgoboss]

✅ bug fixed

[vonglan]

For anyone trying to adapt Luau preset files: if loading the preset does not show an error message (but fails), import it from clipboard.

[seantypedthis]

Found a possible bug. When editing the "Start Timing" parameter in the Global Playback Settings section, if I choose "Custom quantization" and drag the values up or down such that it hits one of the preset Start Timing values, for instance 1/4 or 8/1, my mouse cursor disappears in Playtime and REAPER until I restart the application.

Running REAPER 7.12 on Windows 10.

[helgoboss]

Oops. Noted. I had such issues when I worked on the "cursor lock" and thought I fixed them.

✅ (just marking this as "read", I took note of the issue)

[EachDawn]

Hello!

I don't believe I've seen this mentioned anywhere yet (and I am assuming this is not expected behavior), but I am unable to hear audio clips in Playtime 2 when the audio device buffer size is anything under 256. No level shows on the track and master meters during playback and nothing is heard. Audio playback works fine at those buffer sizes outside of clip engine/playtime 2 ( i.e. media items on a track within the same project play just fine).

Perhaps of note: recording audio clips at buffer sizes under 256 appears to work fine (live monitoring within Reaper works fine as well) , but as just described, nothing is heard after the clip is recorded unless the buffer size is increased to 256 or above.

I have tested this with two different audio interfaces on two different Win 10 machines and can reproduce the behavior consistently.

I often like to monitor and record audio in reaper with low latency fx, so getting Playtime 2 working at smaller buffer sizes is big for me. Thanks!

[Trekopep]

Ah, if it's line ID 6, since that still says fixed for pre.14, I had figured adjustments for pre.15 still hadn't been made. If more fixes have been made for this for pre.15, awesome! Thanks!

[helgoboss]

Oh sorry, it looks like I forgot to mention this in the spreadsheet. It's not line ID 6. It's something else. I'm going to add this as solved bug 45.

[Trekopep]

Looks like I'm still getting a similar error to the previous build. Happens with a buffer size of 192 ("out of range for slice of length 128"), 96 ("length 32"), and 48 ("length 32"), but not any others:

REAPER version:      6.83/x64
Module name:         Helgobox
Module version:      v2.16.0-pre.15/x86_64 rev f9946e (2024-06-13 13:43:22 UTC)
Module base address: 0x7ff8646b0000
Module size:         0x27b5000

Message: range end index 192 out of range for slice of length 128

   0:     0x7ff865d691fb - DllMain
   1:     0x7ff865d66f42 - DllMain
   2:     0x7ff865cd81db - DllMain
   3:     0x7ff865f86723 - cpp_to_rust_PCM_sink_Extended
   4:     0x7ff865f865c9 - cpp_to_rust_PCM_sink_Extended
   5:     0x7ff865f846c9 - cpp_to_rust_PCM_sink_Extended
   6:     0x7ff865f86292 - cpp_to_rust_PCM_sink_Extended
   7:     0x7ff866279187 - cpp_to_rust_PCM_sink_Extended
   8:     0x7ff8662797c4 - cpp_to_rust_PCM_sink_Extended
   9:     0x7ff865bcacb9 - DllMain
  10:     0x7ff865bc473c - DllMain
  11:     0x7ff865ba78e0 - DllMain
  12:     0x7ff865ba762f - DllMain
  13:     0x7ff865bf8384 - DllMain
  14:     0x7ff865beac56 - DllMain
  15:     0x7ff865ba6740 - DllMain
  16:     0x7ff86568860e - DllMain
  17:     0x7ff86568b58e - DllMain
  18:     0x7ff8652187cd - DllMain
  19:     0x7ff8653f9a70 - DllMain
  20:        0x1405c8069 - <unknown>
  21:        0x1400505e6 - <unknown>
  22:          0xdbb4dbc - DllUnregisterServer
  23:          0xdbb4778 - DllUnregisterServer
  24:          0xdbb395c - DllUnregisterServer
  25:          0xdbb403e - DllUnregisterServer
  26:          0xdbb26b6 - DllGetClassObject
  27:     0x7ff8d2f91bb2 - configthreadlocale
  28:     0x7ff8d3367344 - BaseThreadInitThunk
  29:     0x7ff8d507cc91 - RtlUserThreadStart

[helgoboss]

Ah, then this seems to be an unrelated error after all. Will look into it.

[helgoboss]

@Trekopep This was indeed an unrelated error related to block sizes which are not a power of 2. Good catch! Fixed in next version.

[daniellumertz]

In this post I will focus on the design of editing midi, as it is where I am having most difficulty. Besides that, I am having fun and glad to be using it. Please tell me if I am using it wrong, forgetting some settings, I am only starting learning it.

I am having a bit of trouble with the design of editing MIDI, they work best using it docked, which is no problem, as we have docked windows. But I want to point out that having MIDI as window not docked will create a window madness, as it alternates between 2 windows and if you are editing MIDI on the arrange and MIDI on the playtime clips, the number of windows will only rise !! The alternation is also inconvenient as it leaves a window with no take opened ( basically wasting screen space ):
DEMO: https://imgur.com/6GSibDk

Also having it docked and editing MIDI on the arrange will increase the number of docked windows :
https://imgur.com/TRc1Am3

For some reason using it docked creates this empty dock MIDI editor:
https://imgur.com/sWgjx4s

When opening a MIDI from playtime it keeps auto adjusting the height zoom of the pianoroll. Idk if this is from playtime or reapers. I think it might be a cool feature but need more adjustments, changing between clips makes me very confuse as I need to reorient in which octave I am. I would have it as an option, and break it up in two parts: zoom auto adjust and lowest note auto adjust. Also, the zoom auto adjust needs a minimum size per midi editor height. If you have a big MIDI editor window and open a midi take with just one pitch it will get a super unnecessary zoom at it. In the end, these auto adjustments are demanding me more work than less.

For reaper users that have, and are used to, having one midi editor per project, the current way to edit midi is a bit confusing. Maybe all that I have reported is related to that setting and could be solved considering it. So, if the user have 1 MIDI editor per project, instead of opening a new MIDI windows, it would jut put the take at it. Which reminds me that there might not be an API for that ?

I am also not a big fan that, for editing MIDI, it inserts the midi on the track. I get that it needs to insert the item to open the take at the midi editor. I will brainstorm a little, but why not use an hidden track for this? This way wouldn't be intrusive to the arrange view. I also think that having a hidden track holding the midi takes could be beneficial for two more reasons: 1) could open more than one take at the same time. Often I have more than 1 take open at the midi editor and/or have them in visualize only mode (not editable). This way I could edit one clip while having another visible on the background, good to have more references for rhythm, harmony, counterpoint, or edit multiple clipts at the same time. 2) I am having fun using some script to manipule MIDI, while playing at playtime2, currently can only manipule whichever MIDI clip is being edited, which is ok, as my scripts work only with the take being edited. But having it on a hidden track might open some future doors for manipuling more than one at the same time.

My Reaper preferences:

[helgoboss]

I feel you. This is one point which I haven't put too much thought in yet.

Window madness

I actually tested only with "One MIDI editor per project". But what I didn't test is also opening MIDI editors for items on the arrangement. I'm a bit surprised that it suddenly opens a second MIDI editor then.

I would classify this as a bug and I would fix this by making sure that only ever one MIDI editor is open.

Or do you have anything else in mind? What would be your preferred way of handling the MIDI editor?

Auto-zooming

This is done by Playtime and yes, I totally agree that this needs more fine-tuning, a minimum zoom size at the very least. Can you elaborate on the "zoom auto adjust and lowest note auto adjust." options that you brought up? How exactly would that look?

Insertion on the track

Funny you bring that up. Initially, I was using a hidden track for this. I changed it at some point because I wanted to hear the notes being edited. But I could also do that by using a hidden track and creating a temporary send to the instrument track. Yeah, probably less confusing. Will do that.

I'm pretty sure I will add better ways to let scripts manipulate MIDI clips, not just the currently edited one. But if putting things on a hidden track helps you already, that's all the better.

[helgoboss]

✅

• I disabled auto zoom completely. It needs an addition on REAPER side to be implemented in a better way.
• Window madness is tamed now. It should respect the REAPER setting "One MIDI editor per project"
• Using hidden temporary tracks now to instantiate the items.

[daniellumertz]

Playtime2 is crashing REAPER if :
Open project 1 - Insert PT2
Open Project 2 - Insert PT2
Close Project 1

[helgoboss]

✅ (marking as "read", going to fix this issue)

[helgoboss]

@daniellumertz I can't reproduce this. Tested on macOS. On which OS are you? Is there some error message?

BTW, using multiple Playtimes in different tabs is not officially supported yet, for one thing because I didn't test it enough and for another thing because the tempos of the projects are always globally synced at the moment, which is probably undesired.

[helgoboss]

I just improved this. Having multiple project tabs with independent matrixes / independent tempos is now supported. ✅

[daniellumertz]

I am using [record track output] mode to record my improvisations in PT2 I guess, for newcomers to reaper, would be nice to have a shortcut to change the record mode in the PT2 interface ? Mostly to point out the method for the used

Sorry to spam here helgo, I am using it now and taking notes

[helgoboss]

✅ (noted as potential new feature)

[daniellumertz]

A cool feature of playtime 1 and playtime 2 is using midi notes on an item to trigger clips. That is working here, but would be great if the overdub was also mapable, so I can decide some parts to be recording what I play without me having to go click overdub/record etc etc... As I am normally playing keyboards with both hands, would be good a feature to trigger clips on record or overdub via MIDI

On that note, a thing that I is doable in Live with Clyphxpro is to set a clip to record a certain length and then start playing, without the player having to click in nothing to stop recording. Demonstration : 5:30 https://www.youtube.com/watch?v=Yn_ExkefmCQ&t=173s&ab_channel=RobbieSko . It seems possible in PT2 by creating a clip, playing it, putting it on overdub. But by doing this way I have to wait an entire loop because I lost the start putting it on overdub mode.

[seantypedthis]

Oh, I nearly forgot to mention that I was getting an error trying to use the mappable overdub:

Control: Failed to hit target: error while hitting clip transport target [invocation = 67, target = 1, control value = 1] (direct control)

With the invocation value increasing every time I try to trigger. Haven't had too much time to test this past week, but it seemed consistent with the two controllers I attempted to trigger on.

[helgoboss]

Perhaps you have the wrong slot descriptor? Or the slot doesn't contain a MIDI clip already?

[helgoboss]

Or is your expectation that it records normally if the slot is empty?

[seantypedthis]

Ah, my mistake! This is for MIDI overdub, I was attempting to do audio overdub! I just gave it a test and the mappable MIDI overdub works as expected, can disregard my error reporting.

As for audio, I assume overdub would be a completely different implementation, as the slot seems to stacks audio items for simultaneous playback as opposed to recording/adding into an existing item as it does with MIDI.

Sorry for conflating feature requests!

[helgoboss]

No problem. I might add audio overdub at a later point.

[seantypedthis]

Feedback:

• Loving the controller mapping system! It took me less than a day to get something up and running that functions better than my Playtime 1 setup. It did take me some time to stop fighting Playtime's built in mapping logic, I wasn't picking up on the fact the trigger mapping had multiple velocities for different states (I kept trying to make it "on/off"), but now that I understand this, I really appreciate that it provides visual feedback for whether a slot contains a clip, and whether it is inactive, active, or recording. Very useful.

• I'm also learning how to use the "Unit" system so more than one MIDI controller can control Playtime as well as receive feedback. It's still a little messy, but as of now it seems like I'm getting good results using my foot controller and clip launcher/pad controller simultaneously. And I finally got the automapping configured correctly, so the controllers are ready to go whenever I start a new instance.

• Is there a place to upload mappings, or are you waiting for the stable release in case the mapping syntax changes?

A few feature request:

• The tempo detection works really well, but any tempo above 120 bpm gets read as half the tempo. Would it be possible to adjust the detection range? To this point, can tempo doubling and halving in the Material section of a selected clip be MIDI mappable? That would make it easy to modify the selected clip right when it is loaded or when you trigger (I like how the focus switches on trigger).
  Another nice option/fall back could be being able to read BPM from METADATA when BPM is embedded.

• It would also be great if there was support for recording multichannel audio sources. Slots already work well with playback of imported multichannel audio. Comes in handy consolidating and saving slot/track space. For instance, playing back a drum loop that contains snare, kick, hihat, and crash all on separate channels, then using something like the Channel Mapper-Downmixer to control muting/mixing.

• Also, +1 on overdub being mappable, definitely would be another space saver. Would make it so the column could still function in exclusive mode as far as the row/scene is concerned, but still have the ability to record and play back multiple parts from one slot. Not a necessity, just adding a layer of flexibility.

Bug:

• Still having issues with Stereo recoding sources and glitching audio, mono recordings continue to work really well.

[helgoboss]

Loving the controller mapping system! It took me less than a day to get something up and running that functions better than my Playtime 1 setup. It did take me some time to stop fighting Playtime's built in mapping logic, I wasn't picking up on the fact the trigger mapping had multiple velocities for different states (I kept trying to make it "on/off"), but now that I understand this, I really appreciate that it provides visual feedback for whether a slot contains a clip, and whether it is inactive, active, or recording. Very useful.

Also worth to note (not documented yet): There's also a text property available that outputs the clip's play state as text (e.g. "playing") instead of a number. This is leveraged by all the grid controller scripts.

I'm also learning how to use the "Unit" system so more than one MIDI controller can control Playtime as well as receive feedback. It's still a little messy, but as of now it seems like I'm getting good results using my foot controller and clip launcher/pad controller simultaneously. And I finally got the automapping configured correctly, so the controllers are ready to go whenever I start a new instance.

Are you using Playtime's built-in "Global controller settings" for this (the MIDI jack icon on the bottom left)? That would be the way to go, yes. That in combination with Luau presets.

Is there a place to upload mappings, or are you waiting for the stable release in case the mapping syntax changes?

Not yet. I think in the near future I will concentrate on providing more and more factory presets and polish the existing ones (so that they can serve as good examples). I'm not planning to change the mapping API much, but until release it could still happen.

The tempo detection works really well, but any tempo above 120 bpm gets read as half the tempo. Would it be possible to adjust the detection range?

Ha, actually it already is. If you export the complete matrix as Lua, you will see a tempo range property somewhere. But it didn't make it into the GUI yet. I'm planning to add that. Maybe before release.

To this point, can tempo doubling and halving in the Material section of a selected clip be MIDI mappable? That would make it easy to modify the selected clip right when it is loaded or when you trigger (I like how the focus switches on trigger).

I was thinking to provide a mappable tempo factor knob at some point (along with a pitch shift knob) - as a performance tool so to say. My thinking was that only performance tools need to be mappable, not "normal" clip settings such as "Original tempo". But it sounds you want to use a MIDI controller to help adjusting this normal clip setting?

Another nice option/fall back could be being able to read BPM from METADATA when BPM is embedded.

True. Please remind me after release.

[seantypedthis]

Ha, actually it already is. If you export the complete matrix as Lua, you will see a tempo range property somewhere. But it didn't make it into the GUI yet. I'm planning to add that. Maybe before release.

Ah ha! I should have known, it's always in the Lua...more fun stuff to look at!
I've done some experimenting with the tempo min max, and it is indeed giving me a wider range! However, I do feel like it still tends to pick the lowest possible tempo factor, which of course leads to more random fun, but can be less predictable.

I was thinking to provide a mappable tempo factor knob at some point (along with a pitch shift knob) - as a performance tool so to say. My thinking was that only performance tools need to be mappable, not "normal" clip settings such as "Original tempo". But it sounds you want to use a MIDI controller to help adjusting this normal clip setting?

I think that would be a good solution as well. I'm not so much concerned about what Playtime reads the original tempo as, more interested in how that effects playback speed relative to REAPER's metronome. The overall alignment is correct and well detected, it's just a matter of how slow or fast the clip plays, anything that can increase or decrease the factor would suffice. As long as the factor can be controlled/mapped per individual clip (as sometimes you want drums/rhythm to be twice as fast without effecting a pad or a melody, etc..), then I think it would accomplish what I'm thinking.
Ooo, or even including per column or row, in case you want to make a whole part or section half/double time temporarily...hmm, probably more future thoughts..

[helgoboss]

Good point. I should probably try to stick to tempos around 120 first, not start from the lowest possible tempo factor. Fixing.

[helgoboss]

✅ Tempo detection range is now changeable from GUI, tempos closer to 120 bpm are preferred

[seantypedthis]

Tempo detection working rock solid, much more in line with what I'd expect with the original loops/samples I've been testing with. I can see different styles having different center tempos, but 120 bpm seems like a good target to me as well, as it would most likely be used for more electronic music and can kind of swing either way when it comes to other genres. Not to mention it's REAPER's default new install tempo.

Haven't experimented with adjusting the range too wildly yet, but I'll get into the nitty gritty over the next couple days and get back to you if I notice anything strange!

[seantypedthis]

Integrated into my main setup over the past week, and I'm starting to feel some of that old Playtime 1 magic!

Works well, relatively bug free, not pushing too hard however. Saving and loading works well, it actually mitigates issues I was having with the "Show/Hide Playtime" button when other instances of Realearn were already in the project.
If I save an active matrix in the project, load the project and hit the Playtime shortcut, the right matrix/app appears and the "Show Helgobox plug-in" button in the app takes me to the correct Realearn with my mappings!
One caveat, if I then add an instance of Realearn/Helgobox to the monitoring FX, the "Show/Hide Playtime" button still works correctly and shows my existing matrix, however, when I click the "Show Helgobox plug-in" button, it takes me to the mappings for the instance in monitoring fx.

Other than that, so far so good. I had initial difficulties realizing I needed to get rid of tempo markers for sync to work correctly, but once they were gone, recording into slots in time was a breeze using a 1 bar start timing.

If I save and close a project with pre recorded/loaded clips, they all reappear as expected when I load the project back. It even works with @daniellumertz 's Track Snapshots! (Thanks, Daniell!)
So theoretically one could save and load arrangements in this manner!

Know it's in alpha, but getting very tempted to try this out in the wild in the not too distant future...

[seantypedthis]

In my testing, yes, tracks still need to be record armed to function properly.

[helgoboss]

I'm now starting to look into this "record arm glitch".

[helgoboss]

One caveat, if I then add an instance of Realearn/Helgobox to the monitoring FX, the "Show/Hide Playtime" button still works correctly and shows my existing matrix, however, when I click the "Show Helgobox plug-in" button, it takes me to the mappings for the instance in monitoring fx.

Ah okay. Looking into it.

Other than that, so far so good. I had initial difficulties realizing I needed to get rid of tempo markers for sync to work correctly, but once they were gone, recording into slots in time was a breeze using a 1 bar start timing.

I still need to test/optimize for projects with tempo markers. This is definitely an after-the-release thing. Until then I should add a "Doesn't work with tempo markers" remark to the docs.

[helgoboss]

✅ fixed the bug that caused the wrong plug-in instance to be opened

[seantypedthis]

Fix works great, no conflicts with instances of Helgobox/Realearn in Monitoring FX, or on any other track, both in saved projects and new projects after launching a new instance of Playtime using the shortcut.
Starts right out the box with all of my preconfigured controllers ready to go, referencing the correct Realearn when pressing the Show Helgobox button in the bottom left navigation. Thanks!

[bird0912]

Hi @helgoboss ! I've been testing the latest Playtime 2 milestone and I can safely say that it's a beast for live performances :D. I have a few observations, specifically about how things are laid out in terms of UX (menus). Also a couple of bugs I found along the way:

IDEAS:
● Rename Functionality: Enable renaming by double-clicking.
● Enhance Tap Tempo Visibility: Improve highlighting for Tap Tempo (discovered it was in the Playtime name).
● Consolidate Settings: Merge all settings into a single menu, with submenus for general and MIDI settings. (Currently, it's confusing to access UI, global, and MIDI settings in three different places.)
● Channel Creation Prompt: Prompt the user to choose between instrument or audio channel upon creation.
● Column UI Improvement: Add a delete column option anywhere on the mixing UI (e.g., under the cells), making it easier to duplicate or delete a channel, akin to Reaper's fader strip.

BUGS:
● Waveform Loading Animation: The waveform view continues to display the loading animation.
● Arm Record Font Alignment: The font alignment for arm record is slightly off-center.
● Recording Slot Mapping Issue: When clearing a slot while recording, MIDI mapping is lost and cannot be remapped (consider improving clarity for users, possibly through ReaLearn).
● Row Duplication Inconsistency: Duplicating a row doesn't duplicate cells. This might be intentional, but it's less intuitive than copying a whole section.

I don't think anything of this is critical, but I could improve the user experience a little bit :D

This are my machine's specs in case you need them:
LAPTOP-4HMIK5D7
AMD Ryzen 5 4600H with Radeon Graphics 3.00 GHz
RAM 16.0 GB (15.4 GB)
64 bits

Thank you for all the hard work you've been putting into this project, it's phenomenal!!! :D Have a great day! :D

[bird0912]

@helgoboss It gave me the following error:

===== ATTENTION =====

Sorry, an unknown error occurred in REAPER plug-in Helgobox. REAPER should continue to work but Helgobox might show unexpected behavior until restarting REAPER. If you feel like saving your project file at this point, better save it as a new file because this error could have messed up the plug-in state.

In any case, please report this error:

1. Prepare an e-mail containing:
   • The error information further below (IMPORTANT)
   • Some instructions on how to reproduce the error (IMPORTANT)
2. If possible, attach the following files:
   • Your REAPER project file (.rpp)
   • Your REAPER configuration file (reaper.ini)
3. Send it to [email protected]

Thank you for your support!

--- cut ---
REAPER version: 7.15+dev0509/x64
Module name: Helgobox
Module version: v2.16.0-pre.14/x86_64 rev 81eba2 (2024-04-24 17:25:24 UTC)
Module base address: 0x7ffe76f30000
Module size: 0x280c000

Message: REAPER string should be UTF-8 encoded: IntoStringError { inner: "C:\Users\Andr\xe9 Torres\AppData\Local\Temp\REAPEAKS\9b\9bfd4711631de7c9922454d51013ef3cad0771fc.reapeaks", error: Utf8Error { valid_up_to: 13, error_len: Some(1) } }

0: 0x7ffe7882241b - cpp_to_rust_PCM_sink_Extended
1: 0x7ffe78820162 - cpp_to_rust_PCM_sink_Extended
2: 0x7ffe7868c0ab - VSTPluginMain
3: 0x7ffe78840e63 - cpp_to_rust_PCM_sink_Extended
4: 0x7ffe78840d09 - cpp_to_rust_PCM_sink_Extended
5: 0x7ffe7883ee09 - cpp_to_rust_PCM_sink_Extended
6: 0x7ffe788409d2 - cpp_to_rust_PCM_sink_Extended
7: 0x7ffe78b2f897 - cpp_to_rust_PCM_sink_Extended
8: 0x7ffe78b2fdd3 - cpp_to_rust_PCM_sink_Extended
9: 0x7ffe78711d56 - VSTPluginMain
10: 0x7ffe783f82da - VSTPluginMain
11: 0x7ffe783dd28c - VSTPluginMain
12: 0x7ffe773dee0b - invoke_host
13: 0x7ffe786bf540 - VSTPluginMain
14: 0x7ffe7868e9bd - VSTPluginMain
15: 0x7ffe7794b23f - DllMain
16: 0x7ffe7871ca3f - cpp_to_rust_PCM_sink_Extended
17: 0x7ffe78719c83 - cpp_to_rust_IReaperControlSurface_Run
18: 0x14032cab3 -
19: 0x140200c40 -
20: 0x140200019 -
21: 0x1404b5aa5 -
22: 0x7fff13379d16 - GetMenuItemCount
23: 0x7fff13379607 - GetMenuItemCount
24: 0x7fff13394099 - DrawTextA
25: 0x7fff13378961 - DispatchMessageW
26: 0x7fff13378421 - DispatchMessageW
27: 0x1404ac9d8 -
28: 0x140a9c4b1 -
29: 0x7fff1369257d - BaseThreadInitThunk
30: 0x7fff144caa48 - RtlUserThreadStart
--- cut ---

HOWEVER, when I did a portable install with the dev version of Reaper, I can see the waveform :D i'm not exactly shure what's going on, maybe it's conflicting with other packages or with itself. I should note that I installed this new version of Playtime in the portable folder using Reaboot.

[bird0912]

For what I'm looking at the console report, it seems that It can't figure out custom .reapeaks folders, hence the error. I guess hehe. On a related note tho, in the working installation the waveform just displays a section of the hole audio, however, playback cursor seems to be navigating a whole logical waveform. Wierd hehe

[bird0912]

IDEA:
● Allow pitch transposition from clip's audio settings (useful for key matching on the go)

[helgoboss]

Okay, I will look into it myself next week, I was actually able to reproduce this error (with the old REAPER version). Maybe needs more fixing on REAPER side.

On a related note tho, in the working installation the waveform just displays a section of the hole audio, however, playback cursor seems to be navigating a whole logical waveform. Wierd hehe

That's related to the way Playtime records audio material. It records everything, including the count-in phase (exactly like REAPER) and even a few milliseconds more after recording already stopped. This could come in useful for potential future improvements such as automatic cross-fades between loops (instead of normal fades).

There's already an FR scheduled for alpha that is about omitting these parts of the waveform (FR 88): https://docs.google.com/spreadsheets/d/1O7ukcsDO0JHmHpS4k7-6aU29iCKo8kk5jIL4i7MT_98/edit?usp=sharing

Allow pitch transposition from clip's audio settings (useful for key matching on the go)

See FR 4

[bird0912]

I see! I'll keep my eye open then for the new milestone :D

[chords-chords]

Hi Benjamin,

running the "Show/hide Playtime" action returns the following error message and no UI is shown:
"The system cannot find the path specified. (os error 3)"

I'm running ReaLearn 2.16.0-pre.14 and Reaper 7.15 (installed in "c:\Program Files\REAPER (x64)") on a Windows 10 x64 machine. I updated ReaLearn via ReaPack.

[helgoboss]

You need to install Helgobox, not ReaLearn.

[chords-chords]

Thanks and I apologize for not reading the instructions carefully. I now attempted to install Helgobox via ReaPack but it returned errors that ReaLearn's .dll file is already in use. I then installed it via ReaBoot which worked. Now Playtime launches properly.

[indigomirage]

Hi Helgoboss -

Thank you for all the incredible work you've done here. I've got a FR to throw onto the pile...

Would it be possible to have PT2 handle multichannel audio (even if only allowing dragging multi-channel audio media items onto the grid)? In my case, I always record guitar and bass with 4 channels (2 'wet' (L/R), 1 raw, 1 dummy). This lets me re-amp the performance very easily if I need to tweak it. It's also especially handy when comping tracks where you don't want to slice into reverb tails (and when looping via PT2, this would be especially beneficial). If PT2 could handle multichannel, it would go a long way to easing workflow.

Cheers!

[indigomirage]

This is making a lot more sense. I, in particular, feel foolish not putting two and two together on this because about 1 yr ago, I put in a feature request to the Reaper folks to extend the API for renders (for drag and drop) to specify the output file format so that I could convert to wav on the way to Maschine. And they put it in (https://forum.cockos.com/showthread.php?t=275666)! Perhaps there's a hook to specify a channel count override (assuming it caps it at whatever the Master channel has)...

EIther way - this is very good. I understand the necessary workarounds (and importantly why they are needed)...

Question - when you do your internal fix to respect the crop length when importing selected via menu, will you be doing it by creating a render? Or by capping the length in the slot's config? (I only ask because I didn't see reference to this - or channel count - in the lua exports for slots as I was trying to unravel all this)

[helgoboss]

Question - when you do your internal fix to respect the crop length when importing selected via menu, will you be doing it by creating a render? Or by capping the length in the slot's config? (I only ask because I didn't see reference to this - or channel count - in the lua exports for slots as I was trying to unravel all this)

Nah, no rendering. That would be unnecessary. I will use the Playtime clip section feature for that. It allows to change start position and length. Playtime actually maintains 2 sections by clip. A fixed one (supposed to stay the same most of the time) and a dynamic one (one that you can play with e.g. as part of a performance, and currently the only type of section that you can edit from the GUI). I think I will take the fixed one for this purpose. Then the non-contained parts will not be visible in the waveform editor (at least starting from Helgobox 2.16.0-pre.15).

[helgoboss]

BTW, this is not the only thing missing from "Import selected item into slot". Improvements of this feature are on my internal todo list. No need to report more bugs related to this particular feature. Best wait until pre.15 and try again.

[indigomirage]

I suspect that any use of Reaper's media item drag and drop will inevitably call its 'Render Media Item to New File', and might cause a lot of bloat in the project media folder.

I've raised a question as to whether channel count can be preserved in this operation on the Reaper forum, and will make it a bug report if it's not just my own idiocy. (Any bug would be Reaper's, not yours, here...)

The main point here is that drag and drop with this feature could be fraught because of all the new files being spawned. Simply 'cleaning project directory' would be risky, as I doubt Reaper would be aware which files are being used by Playtime2.

You might be better with some sort of API/Action... though could make for a tricky UI?

[helgoboss]

I will sort it out with Justin and find the best way possible, no worries. For now, it's best to consider the "drag item into Playtime" feature as non-existent and use "Import selected item into slot" instead.

Supporting "Clean project directory" is also on the spreadsheet list BTW. There's a REAPER API for that (C++ only AFAIK).

[seantypedthis]

Hey Benjamin!

I realized that a bug I reported last week on the Realearn thread is more than likely related to the Helgobox version of Realearn, as that is the one I've been using. I just updated to the latest version (glad to hear you're getting time to actually make music with the fruits of your labor!), and the issue seems to persist.

It appears that two things are happening in my particular case, both having to do with instance starting. The Program Change button on one of my controllers (QuNeo) begins to constantly fire, and a few tracks I have set to toggle "bypass fx" in a timed manner get stuck rapidly feeding back.

Also, if I stop/start the audio engine, the issue appears to fix itself.

Attaching a short video and a sample project file, thanks!

Helgobox Init Bug 062024.zip

In addition, after drafting this message, I tried unchecking "Poll for feedback" on the fx bypass mappings. It seemed to solve the issue in this sample project for fx bypass (not for the Program Change issue), however it did not solve the fx bypass issue in my main patch...so let me know if you want me to send over that tangled mess, haha.... Thanks again!

[helgoboss]

Oh, and in order to avoid future confusion: Helgobox ReaLearn and normal ReaLearn are 100% the same, there's no difference.

[seantypedthis]

Thanks for always being on it!

And duly note, will make sure to treat them as one and the same. I think vaguely had that understanding, but I didn't want to accidentally conflate the two in case it was relevant.

[helgoboss]

You were right, it was related to the fire mode changes. I introduced a bug that would let fire mode "Fire after timeout" work a bit like "Fire after timeout - Keep firing". Fixed in pre.18

[seantypedthis]

Wish I had more time to test in the coming weeks, but just wanted to make sure I confirmed the bug as indeed squashed, thanks Benjamin!

[helgoboss]

Thanks for letting me know! No pressure.