v4.16pre15 - February 12 2012

[Sexan]

OSC doesn't refresh states (folder position etc.) until you Open control surface settings and click OK (this is on Android don't know is this issue is on iOS)

[schwa]

Originally Posted by Sexan

OSC doesn't refresh states (folder position etc.) until you Open control surface settings and click OK (this is on Android don't know is this issue is on iOS)

There is an action "Control surface: refresh all control surfaces" which will force an update. But, moving a track should automatically update .. what specific action are you doing, that is not updating the surface?

[Sexan]

It is updating while I'm moving faders but if I close and open application all faders (in touchosc) are on same position,but after I Open edit control surface an click ok then all positions update to reaper fader positions.Im only moving faders nothing else.The initial position of faders is what I'm talking about

That action updates the fader state but crashes TouchOSC in few seconds,maybe its android related I'm on Ice Cream Sandwitch.Anyone with stock Android can confirm?And edit window too sometimes crashes TouchOSC

[Banned]

[OT] When I made my avatar for this forum (a few years ago already), I had also been nagging schwa a bit on IRC for OSC support, and had poked Justin about it (@askjf). The avatar kind of symbolized my wish to (more easily) control REAPER from my iPhone (brand new, back then), which pretty much implied the need for native OSC support.

Now that I'm getting what I wished for (even though a bit rough around the edges, no doubt we can look forward to many further refinements), I ponder whether I should change it to reflect another long held wish for some REAPER improvement (and I do have quite a list of those, as most of us here do... ), or proudly keep wearing it, but from now serving a different purpose, namely a badge of honor. Until I come up with a better one, I think I'll opt for the latter.

Anyway, once again, thank you Cockos!

[schwa]

The same action to refresh the control surface is sent automatically when opening a new project. If your OSC client app is crashing, it's either because REAPER is sending some malformed messages, or because the app is getting flooded and can't handle it. To check the second possibility, could you try changing the packet settings to a smaller max packet size (say 256) and a longer wait between packets (say 50ms)? The surface will update much more slowly but if it doesn't crash, that will tell us the problem is the app not being able to handle the incoming data.

[Sexan]

Originally Posted by schwa

The same action to refresh the control surface is sent automatically when opening a new project. If your OSC client app is crashing, it's either because REAPER is sending some malformed messages, or because the app is getting flooded and can't handle it. To check the second possibility, could you try changing the packet settings to a smaller max packet size (say 256) and a longer wait between packets (say 50ms)? The surface will update much more slowly but if it doesn't crash, that will tell us the problem is the app not being able to handle the incoming data.

Still crashes after that settings But now it takes a little longer to crash

Edit: after testing again,crashes client all the time,cant even move the fader in reaper (50ms wait) but if restored to 10ms it doesn't crash if I move faders in reaper

[Sexan]

One more observation ,it only crashes when initial position of faders are not the same,if I move the faders then apply that action app doesn't crash

[Banned]

Originally Posted by plush2

# Updated zlib/libpng to latest versions

Could this be related? When I was just playing around, this happened to a UAD-2 plugin (AU version, OS X 10.7.3, could not reproduce):


NB: there are supposed to be LEDs inside the red circle I added to the screenshot. When closing and re-opening the plugin GUI, it got worse:



Other plugin GUIs were apparently not affected.

[l0calh05t]

Originally Posted by Banned

Could this be related? When I was just playing around, this happened to a UAD-2 plugin (AU version, OS X 10.7.3, could not reproduce):


NB: there are supposed to be LEDs inside the red circle I added to the screenshot. When closing and re-opening the plugin GUI, it got worse:



Other plugin GUIs were apparently not affected.

Unlikely. The plugin uses it's own PNG loading code, if any (it doesn't have access to the symbols linked into Reaper. It would also be pretty silly if it did and used them, because then it wouldn't work with hosts that do not use libpng).

[Viente]

Where is the disable VU meter in the context menu now? Can't see it anymore

[Mercado_Negro]

Originally Posted by Viente

Where is the disable VU meter in the context menu now? Can't see it anymore

Oops, the spaghetti monster ate it

[Viente]

Originally Posted by Mercado_Negro

Oops, the spaghetti monster ate it

Could he puke it back please??

[Justin]

Originally Posted by Viente

Where is the disable VU meter in the context menu now? Can't see it anymore

It is in the track context menu, under "track performance options"

[Justin]

Originally Posted by nicholas

Input Monitoring (and maybe more) has been removed from the arm record right click context menu in this release.

Please, please, please guys believe me that this will just cause confusion and frustration to many, many users, who are used to using this method.

Yeah, I think I agree here -- the record button context menu should have everything; the other contexts can have reduced version, but having everything record related in one place seems like a big win in general.

[Justin]

Originally Posted by Banned

Just having switched on Monitor Input should have sufficed to hear the plugin instrument being played from the selected MIDI input.

I suppose enabling monitoring should also enable record arm if record arm isn't already set. I guess this should be an option...

[EvilDragon]

Originally Posted by Justin

I suppose enabling monitoring should also enable record arm if record arm isn't already set. I guess this should be an option...

No, not really. They should remain separate. It's just that only in case a MIDI input is selected, enabling monitoring should let the sound of the virtual instrument through, we shouldn't need to enable rec arm separately for that.


Although, for me personally it's not a too big issue - I use auto-rec-arm most of the time. But it's not failproof either. It happened way too many times - I HAVE NO SOUND, WTF IS HAPPENING?! only to notice that the VSTi I wanted to hear was not auto-rec-armed because the track was magically deselected by me doing something else in the project.

Originally Posted by Justin

Yeah, I think I agree here -- the record button context menu should have everything; the other contexts can have reduced version, but having everything record related in one place seems like a big win in general.

As a modifier or a checkbox option, please. (Checkbox by default to show all record related options in one place.)

[Viente]

Originally Posted by Justin

It is in the track context menu, under "track performance options"

Cool! Thanks Justin

[Mercado_Negro]

Originally Posted by Justin

Yeah, I think I agree here -- the record button context menu should have everything; the other contexts can have reduced version, but having everything record related in one place seems like a big win in general.

What if we had a "Set track recording options" sub-menu in the track right-click context menu? Would that be pointless and clutter the current menu? I'd really like to keep these 3 menus focused on their tasks, it looks really good right now

[chucky5p]

Originally Posted by plush2

# record input menu: more tweaks

+1 Another vote from me. Love this arrangement, we can have all inputs changes to the same input or assign them sequentially.

Thanks!

[Mercado_Negro]

Originally Posted by EvilDragon

No, not really. They should remain separate. It's just that only in case a MIDI input is selected, enabling monitoring should let the sound of the virtual instrument through, we shouldn't need to enable rec arm separately for that.)

Yeah, it makes sense for MIDI. With audio is different because it'd be a mess if we had several tracks set to the same input and "monitored". It'd be pretty much like using the rec-arm button, we had to "enable" it (monitor on) to hear our performers.

[TeaBone]

Hi, nice stuff going on here at the OSC front!

However, I have encountered an erroneous behaviour with the send pans. Here's what's happening:

(using TouchOSC on iPhone)

I create a centered fader (or rotary, doesn't matter) in the TouchOSC Editor with the command "/track/send/1/pan", with a value range from 0 to 1. And that's already the problem: Reaper recognizes the values, with 0 being hard left, 0.5 being center and 1 being hard right, BUT sends values from -1 to +1 back to TouchOSC, with -1 being hard left, 0 being center and +1 being hard right. So let's say I send to Reaper a pan value of 0.75 (somewhere between center and right). Reaper sets the pan accordingly to 50%R. Now I switch to the next track vie "/track+", and then back again via "/track-", just to see if the pan position is still there. But NO! TouchOSC suddenly gets a value of 0.5, which it interprets as center. So Reaper obviously is sending values between -1 and +1, where 0.5 matches 50%R. Also, the pan display of TouchOSC isn't refreshing when I change the send pan in reaper. But it gets updated with the wrong value when i switch tracks back and forth via "/track+" and "/track-".

I tried the same with the normal channel pan, but everything works fine there, values from 0 to 1 are passed along in both directions, and the display on TouchOSC is updated instantly.

Sorry for that long text, but I don't know how to put this short AND clear... :-/

[l0calh05t]

Originally Posted by EvilDragon

No, not really. They should remain separate. It's just that only in case a MIDI input is selected, enabling monitoring should let the sound of the virtual instrument through, we shouldn't need to enable rec arm separately for that.

Why only in the case of MIDI?! IMO when monitoring is on, monitoring should be on even if record is unarmed (of course not in the case of tape style monitoring). Both for audio and MIDI. And for me personally especially for audio.

[l0calh05t]

Originally Posted by Mercado_Negro

Yeah, it makes sense for MIDI. With audio is different because it'd be a mess if we had several tracks set to the same input and "monitored". It'd be pretty much like using the rec-arm button, we had to "enable" it (monitor on) to hear our performers.

That would be a situation that calls for tape-style monitoring which only monitors when something is actually being recorded (and it already exists). Makes far more sense IMO.

[Mercado_Negro]

Originally Posted by l0calh05t

That would be a situation that calls for tape-style monitoring which only monitors when something is actually being recorded (and it already exists). Makes far more sense IMO.

But then, how would I listen to the performer while I'm not recording?

[l0calh05t]

Originally Posted by Mercado_Negro

But then, how would I listen to the performer while I'm not recording?

By switching that track to regular monitoring?

EDIT: Besides, have you considered that some people might also use the same MIDI input multiple times, so the situation is in fact exactly the same.

[Mercado_Negro]

Originally Posted by l0calh05t

By switching that channel to regular monitoring?

And isn't that the same as hitting rec-arm? (steps/clicks-wise) What'd be the benefit here?

[l0calh05t]

Originally Posted by Mercado_Negro

And isn't that the same as hitting rec-arm? (steps/clicks-wise) What'd be the benefit here?

The same as with MIDI. Monitoring and record arming functionality are separated.

[Mercado_Negro]

Originally Posted by l0calh05t

By switching that track to regular monitoring?

EDIT: Besides, have you considered that some people might also use the same MIDI input multiple times, so the situation is in fact exactly the same.

But the most common scenario is "one guy playing one MIDI instrument", no? Besides, what's the point of having them separate? Don't take me wrong man, I've always felt there is something wrong in the whole "rec-arm/monitor/disable recording" paradigm in REAPER but I've never been able to put my finger on it. That's why I ask all these questions. I always aim at "makes sense" and "intuitive".

[l0calh05t]

Originally Posted by Mercado_Negro

But the most common scenario is "one guy playing one MIDI instrument", no? Besides, what's the point of having them separate? Don't take me wrong man, I've always felt there is something wrong in the whole "rec-arm/monitor/disable recording" paradigm in REAPER but I've never been able to put my finger on it. That's why I ask all these questions. I always aim at "makes sense" and "intuitive".

And in the case of audio, the most common case is one guy playing a guitar through an amp sim. The point of them being separate is that if you switch monitoring on you would (at least I would) expect monitoring to be on, independent of record arming.

[Spyrow]

Just stopped by to say thanks about the OSC support

It works wonders with FX too, but i'm only getting the first 4 parameters (page 1) and it seems like I can't navigate thru the next pages to access the next parameters.

[Banned]

Originally Posted by Justin

I suppose enabling monitoring should also enable record arm if record arm isn't already set. I guess this should be an option...

I think I'm with EvilDragon, but this would already be quite an improvement. Justin's suggestion would at least have the benefit of showing (novice) users how things are related in REAPER. When a different button lights up as well as the one clicked, I imagine one would more intuitively see or at least wonder how things work, and dig deeper when needed.

But I still think somehow things should be easier, simply because they should be less convoluted. Like I pointed out in my (probably not uncommon) example, I may have no intention of recording anything at all, often I just want a track to host an instrument plugin and play incoming MIDI, and send audio out somewhere (yay crazy routing options). I'd think that even having to look under a button labeled 'Record: ' may be too misleading/confusing for novice users.

Originally Posted by Mercado_Negro

Yeah, it makes sense for MIDI. With audio is different because it'd be a mess if we had several tracks set to the same input and "monitored". It'd be pretty much like using the rec-arm button, we had to "enable" it (monitor on) to hear our performers.

I think we all understand and respect that (e.g.) audio recording oriented workflows are different from MIDI / virtual instrument based workflows, and that it is difficult enough to find one approach that is best suited for a plentitude of users/workflows. The question, obviously, is which approach that would be.

Maybe it would make sense to be able to set up a track for hosting a MIDI instrument slightly different in some way (track performance options?) to optimize it for different workflows - I like the unified track approach in REAPER very much, but some stuff is or at least seems (labelling, GUI) too audio-specific for MIDI-oriented workflows, and thus can become confusing/messy.

Another example where I think where it would make sense to have the same button function different whenever a MIDI instrument is present in a track, is the mute button (NB: I'm not trying to interject FRs into cleanup phase here, simply providing the example for discussion). For audio, it may make sense to abruptly cut off audio when a track is muted; however, for MIDI I would much prefer it to just ignore any further MIDI notes (with two separate approaches: cut off playing notes, if any, by sending note-offs, or continue playing all currently playing notes until their corresponding note-offs), and not have nasty clicks and pops ruining the audio output. In practice, this forces me to forego the potential niceties of a unified track approach, and use separate tracks for MIDI and VSTi/AUi plugins. Imho, (novice) users shouldn't have to figure out such workflows (or perhaps workarounds) to avoid unmusical output from music software.

[Banned]

Originally Posted by Mercado_Negro

But the most common scenario is "one guy playing one MIDI instrument", no? Besides, what's the point of having them separate? Don't take me wrong man, I've always felt there is something wrong in the whole "rec-arm/monitor/disable recording" paradigm in REAPER but I've never been able to put my finger on it. That's why I ask all these questions. I always aim at "makes sense" and "intuitive".

Most common, perhaps. But many of us have a multitude of MIDI gear, and REAPER really should not care about the number of guys banging buttons and tweaking knobs. The number of girls, perhaps so.

I'm 100% with you on asking questions to make things more sensible and intuitive. keep it up.

[schwa]

Originally Posted by Spyrow

It works wonders with FX too, but i'm only getting the first 4 parameters (page 1) and it seems like I can't navigate thru the next pages to access the next parameters.

If your device can only display 4 FX parameters, you'll need to edit the default.reaperosc file and set NUM_FX_PARAMS to 4.

[Seventh]

Originally Posted by Justin

I suppose enabling monitoring should also enable record arm if record arm isn't already set. I guess this should be an option...

Originally Posted by EvilDragon

No, not really. They should remain separate. It's just that only in case a MIDI input is selected, enabling monitoring should let the sound of the virtual instrument through, we shouldn't need to enable rec arm separately for that.

I think it should also work with audio. The current behavior has it's advantages and disadvantages, so it should be made optional (monitor audio/midi/both?).

Current behavior's

Advantages: you can record without monitoring.

Disadvantages: you have to click both the record arm and monitor input buttons if you want to play a MIDI instrument for example, or when you want to hear the speak mic from the recording space (and in this case you'll also have to check "record disable" so it's three steps instead of one).

So yeah, I agree that we could use an option to enable input without record arm, but this should also work with audio, and should be optional!

[Mercado_Negro]

Originally Posted by l0calh05t

And in the case of audio, the most common case is one guy playing a guitar through an amp sim. The point of them being separate is that if you switch monitoring on you would (at least I would) expect monitoring to be on, independent of record arming.

Heh my most common scenario is a singer, not a guitar player. And, in the case of a guitar player, what if we need several tracks "ready to record" a second take (I use the take system but I know people who use several tracks to record takes)? I'd have to set all those tracks to monitor off and just one to tape-style which is pretty much like having all set to monitor on and rec-arm the one I need to record in.

People can set up all new tracks to Monitor Input by default and only rec-arm it when they need to hear/record what someone plays/says/sings. The problem seems to the labeling, no? "Monitor" suggests "I can hear" and that's what confuses people, right?

[diversgens]

Can someone explain the syntax to use for OSC.
I have Lemur for Ipad, communication between ipad and reaper is OK, i can listen to message send by Lemur on OSC0 on port 8000 but i can't control devices on Reaper. I use the default.ReaperOsc file

I want to control the master volume, the listening to port 8000 return:
/mastervolume [f] 0.483791
/mastervolume [f] 0.557993
/mastervolume [f] 0.625712
/mastervolume [f] 0.662163
/mastervolume [f] 0.668122 and so on
but the Volume on Master doesn't move.
Do i have to name the Fader on Lemur MASTER_VOLUME ?

Can someone who succeed to configure OSC with Reaper help me ? TIA

[l0calh05t]

Originally Posted by Mercado_Negro

Heh my most common scenario is a singer, not a guitar player. And, in the case of a guitar player, what if we need several tracks "ready to record" a second take (I use the take system but I know people who use several tracks to record takes)? I'd have to set all those tracks to monitor off and just one to tape-style which is pretty much like having all set to monitor on and rec-arm the one I need to record in.

Uhm, why would you have all set to monitor off?! The idea is to set those you only want to monitor while recording (and record armed) to tape-style monitoring and the single one you want to monitor currently without recording to regular monitoring.

[Banned]

Originally Posted by l0calh05t

Unlikely. The plugin uses it's own PNG loading code, if any (it doesn't have access to the symbols linked into Reaper. It would also be pretty silly if it did and used them, because then it wouldn't work with hosts that do not use libpng).

It doesn't seem anywhere near critical enough to me to get worried, but just wanted to mention it since I thought it might be relevant to something the Cockos devs are currently working on. I was wondering because I hadn't seen this happening before.

Fwiw, I do often get similar artifacts on REAPER's app icon when rendering and CMD-TABbing between apps (that I don't ever see on other OS X app icons), so I just have a hunch some graphics related code between REAPER and OS X has some little bug hiding somewhere, wherever it may be.

[Banned]

Originally Posted by Mercado_Negro

[...] The problem seems to the labeling, no? "Monitor" suggests "I can hear" and that's what confuses people, right?

After they overcome the initial confusion they may have about "monitor" suggesting "I can see" something if I press this button...

[Viente]

Just one "checkbox" in preferences could solve all your discussions