Old 04-27-2012, 12:42 PM   #41
TonE
Human being with feelings
 
Join Date: Feb 2009
Location: Midi automateable sends. Only via OSC.
Posts: 1,127
Default

Quote:
Originally Posted by Banned View Post
The screenie of the patch on its homepage sure *looks* about as elegant as something made with Pd ...
No, the screen you do not need at all, GUI you need only if you want to change anything via the GUI, I never want. Just run key.exe, activate your code, minimize it, finished. It will do its job.
__________________
Volume mixing via jogwheeling with mouseovering. Yeah!
Check my Reaper real-time usage ideas.
boreg made it, never hanging notes in Reaper again! Thanks boreg! boreg & bang.
TonE is offline   Reply With Quote
Old 04-27-2012, 12:49 PM   #42
Guido
Human being with feelings
 
Join Date: Nov 2007
Posts: 674
Default

Quote:
Originally Posted by TonE View Post
No, the screen you do not need at all, GUI you need only if you want to change anything via the GUI, I never want. Just run key.exe, activate your code, minimize it, finished. It will do its job.
Hi,
Late again! Man that keyedit looks way cool..and the GUI ;ools like it came from the atari version of Notator.Thx Tone!

Guido
Guido is offline   Reply With Quote
Old 04-27-2012, 12:50 PM   #43
Guido
Human being with feelings
 
Join Date: Nov 2007
Posts: 674
Default

Quote:
Originally Posted by TonE View Post
No, the screen you do not need at all, GUI you need only if you want to change anything via the GUI, I never want. Just run key.exe, activate your code, minimize it, finished. It will do its job.
Hi,
Late again! Man that Keykit looks way cool..and the GUI looks like it came from the atari version of Notator.Thx Tone!

Guido
Guido is offline   Reply With Quote
Old 04-27-2012, 12:53 PM   #44
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 3,713
Default

Quote:
Originally Posted by TonE View Post
No, the screen you do not need at all, GUI you need only if you want to change anything via the GUI, I never want. Just run key.exe, activate your code, minimize it, finished. It will do its job.
Still, same as Pd. Just without any code activation requirements. And you don't need to minimize non-existent windows either, which saves yet another click.

So, you think it's up to the challenge?
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 04-27-2012, 01:56 PM   #45
TonE
Human being with feelings
 
Join Date: Feb 2009
Location: Midi automateable sends. Only via OSC.
Posts: 1,127
Default

Quote:
Originally Posted by Banned View Post
So, you think it's up to the challenge?
Just have a closer look to the Keykit programming language, then tell me what you like more, pd or Keykit? I am sure pd is also great, I looked at it a little long time ago, but as I had already some experience with Keykit, pd had no chance against its coolness, but only from my point of view. Others with different experiences might see it differently. Nowadays people want to use and buy crap tools, like iBad or similar, ignoring most powerful tools like Keykit, but is it my problem? No.

If I should have anything usable one day for OSC <--> midi conversion using Keykit, of course I can share it also here. Just the lack of send level control in Reaper would be the reason to implement something like this. I would not do it, if I would not have to do it. I suppose Reaper will stay for a longer time without any appropriate send level control, via external hardware controllers. Actually in my case for this particular scenario I would not even do any OSC --> midi conversion then, doing everything only via OSC. Keykit <--> OSC <--> Reaper. No midi at all. Midi is only required if the data has to leave the computer, to other devices, e.g. hardware midi controllers.
__________________
Volume mixing via jogwheeling with mouseovering. Yeah!
Check my Reaper real-time usage ideas.
boreg made it, never hanging notes in Reaper again! Thanks boreg! boreg & bang.
TonE is offline   Reply With Quote
Old 04-27-2012, 03:55 PM   #46
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 3,713
Default

Quote:
Originally Posted by TonE View Post
Just have a closer look to the Keykit programming language, then tell me what you like more, pd or Keykit? I am sure pd is also great, I looked at it a little long time ago, but as I had already some experience with Keykit, pd had no chance against its coolness, but only from my point of view. Others with different experiences might see it differently. Nowadays people want to use and buy crap tools, like iBad or similar, ignoring most powerful tools like Keykit, but is it my problem? No.

If I should have anything usable one day for OSC <--> midi conversion using Keykit, of course I can share it also here. Just the lack of send level control in Reaper would be the reason to implement something like this. I would not do it, if I would not have to do it. I suppose Reaper will stay for a longer time without any appropriate send level control, via external hardware controllers. Actually in my case for this particular scenario I would not even do any OSC --> midi conversion then, doing everything only via OSC. Keykit <--> OSC <--> Reaper. No midi at all. Midi is only required if the data has to leave the computer, to other devices, e.g. hardware midi controllers.
I guess I misunderstood your (desired) use case - mainly out of curiosity, what do you want to use MIDI for then, if not external hardware controllers? Apparently it is not about controlling the sends from another app using MIDI, because you assume (wrongly, imho) that MIDI is only needed for external hardware?

So I'm confused there... I may misunderstand completely what you're intending to do, but it seems that you have things the wrong way around: if you don't need MIDI, but have some way of using OSC from wherever it is you want to control REAPER (KeyKit? KeyKit <--[OSC]--> REAPER should already work), you don't need any conversion tools *now*. You only need REAPER to support MIDI controllable sends natively if you don't want to rely on any OSC<-->MIDI conversion now. Regardless which tool you'd use for that (KeyKit, Pd, whatever).

And I really thought this thread was about workarounds for the time being, so I don't see the need to repeat the desire for native MIDI control. All of us are on your side there already.

But when you say that REAPER has a "lack of send level control" or that it remains "without any appropriate send level control," I respectfully disagree. That is simply not true. I'm happily using a very appropriate track send level control in REAPER as we speak, thank you very much Cockos.

As far as your KeyKit vs Pd question goes, first of all, I explicitly mentioned that my suggested approach to solve the issue that this thread is about is not about Pd, and that you should just use any tool that suits you. And prior experience is a major factor for me to, so I completely understand you taking that perspective, and I have no need or desire to convince you otherwise.

But, fair enough, I drew a comparison with regard to its looks, so I'll be glad to play a little head to head comparison game for a bit. It may be quite informative for some people who haven't found a tool they're comfortable with yet, and want to compare the many possible alternatives. But also keep in mind that I never implied Pd was the best or my favorite tool. To reiterate: I'm mainly mentioning it as a prime example because it is free and cross-platform. Partly because I know I can expect many bitter or hateful comments on this forum anyway (much like your "iBad" reference, which has absolutely nothing to do with the subject of this thread afaics).

So let's start there: KeyKit is also free and cross-platform (I haven't downloaded it and tried it but since Mac is mentioned I'll assume it works as well as the Windows version). To an objective newcomer, which I think is a fair standard, that arguably makes an opening score of 2-2. It doesn't look prettier, at first sight, so that's probably a tie, no points on either side for easy slick looks I guess (I think we agree that looks are secondary to functionality, or even unimportant, right? Which may not be true for everybody though, so I would have given points if either of these two apps deserved them). The most important difference, I guess, is that KeyKit is more of a programming language and less of a programming environment than Pd, i.e. low-level vs. high-level programming approach. Both approaches have their merits, and both are probably pretty powerful, so even while I think the high-level approach is probably easier to grasp for the newcomer, it very much depends on preference and prior experience, and low-level programming typically results in more efficient CPU usage,so for power, I'll give two points to both (4-4). However, Pd can be freely expanded using low-level programming languages, while KeyKit seems a proprietary project (as a lawyer who has worked in telecoms extensively, I do not take signing a license with AT&T's name on it lightly, especially to speak a language, to learn it, or to even have a look at it, sorry). I'll ignore my personal legal objections here (heck, I even gave KeyKit a point already for being available "for free", while it is free only as in free beer), but on expandability Pd must surely win a point over KeyKit (5-4). After a quick scan, it seems to me that the development/support team is tiny (a single guy?), there's not a very large or active user base, but it definitely does look very mature (developed since 1996), so I'll have to assume it's well tested and stable (although I just read somewhere that OSC over UDP is broken on Linux and has never been tested... seriously?), and portability seems good: lots of ports, but mostly to older OSs, and not to modern mobile / DIY platforms like iOS, Android, Arduino. Let's give 2 points to Pd and 1 to KeyKit, making it 7-5. Since I can't think of any other (important) criteria at the moment, I'll end the contest here. End score: a modest but fair win for Pd after against a very decent competitor. By no means kicking its butt, but a fair win nonetheless.

At least, I tried to be fair... I invite you to give me your account of the match. Especially after you've actually tried this approach a bit more in practice, I'm sincerely interested to hear about your results. And the ones of other users, too! Feel free to change the contestants as well.

Btw, for those type of people that prefer programmer-oriented low-level language workflows, you may also be interested in things like ChucK and SuperCollider. And since KeyKit apparently uses SimpleOSC for OSC stuff, perhaps combining that with ReaScript is also an interesting (Python-based) approach.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 04-27-2012, 09:54 PM   #47
TonE
Human being with feelings
 
Join Date: Feb 2009
Location: Midi automateable sends. Only via OSC.
Posts: 1,127
Default

Quote:
Originally Posted by Keykit/doc/history
The development of the KeyKit language began in 1986 (or so)
in response to the rigid interfaces and capabilities of the
sequencers available at that time.
Quote:
Originally Posted by Banned View Post
But when you say that REAPER has a "lack of send level control" or that it remains "without any appropriate send level control," I respectfully disagree. That is simply not true. I'm happily using a very appropriate track send level control in REAPER as we speak, thank you very much Cockos.
Yes, but only via OSC.


Quote:
Partly because I know I can expect many bitter or hateful comments on this forum anyway (much like your "iBad" reference, which has absolutely nothing to do with the subject of this thread afaics).
iBad is not invented by me, but Richard Stallman. You might still love iBad, which is ok. See http://www.youtube.com/watch?v=WGkNiRFwmOg

Quote:
I invite you to give me your account of the match.
I just like Keykit as a programming language. Simple, elegant, powerful.

Yes, combining Keykit via OSC with ReaScript/python might be another nice dimension.
__________________
Volume mixing via jogwheeling with mouseovering. Yeah!
Check my Reaper real-time usage ideas.
boreg made it, never hanging notes in Reaper again! Thanks boreg! boreg & bang.
TonE is offline   Reply With Quote
Old 04-28-2012, 04:55 AM   #48
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 3,713
Default

Quote:
Originally Posted by TonE View Post
Yes, but only via OSC.
Exactly. Which makes me think that using OSC is the best approach, at least for now.
Quote:
Originally Posted by TonE View Post
iBad is not invented by me, but Richard Stallman. You might still love iBad, which is ok. See http://www.youtube.com/watch?v=WGkNiRFwmOg
That does not make it less hateful or bitter, imho. Implying that it it is a matter of subjective love/hate does not help much either. I do understand that we all have our personal pet peeves, and may occasionally mention them out of context. I'm guilty of that myself as well (please correct me whenever I do).

But if you actually intended your iBad comment to refer to the context that you are now providing, that makes it outright ridiculous. If you would understand and agree with the basic principle that mr. Stallman stated there (as well as on many other occasions - I'm quite familiar with the FSF lawyers, their ideology and legal framework), you would use it as an argument against using KeyKit, since it's proprietary software (I can almost hear mr. Stallman's roaring laughter, but I must be imagining it). I'll be happy to correct the match results according to the RMS rules: KeyKit disqualified, so Pd wins by default?

Quote:
Originally Posted by TonE View Post
I just like Keykit as a programming language. Simple, elegant, powerful.
Aside from discussions on moral, ethical and legal principles (and assuming that the average REAPER user doesn't care about those much more than the average human), of course that's what really matters in practice for getting results. I'm glad you found something that works for you, and I hope we'll hear more about your experience with it. I'd appreciate it very much if you could show us a little example of how KeyKit can be used to tackle the issue of controlling send levels. That could be helpful for all of us REAPER users looking into possible solutions to our workflow issues.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ

Last edited by Banned; 04-28-2012 at 05:02 AM.
Banned is offline   Reply With Quote
Old 04-28-2012, 01:53 PM   #49
TonE
Human being with feelings
 
Join Date: Feb 2009
Location: Midi automateable sends. Only via OSC.
Posts: 1,127
Default

Then you should also know: The term "FRAND" is a FRAUD.
__________________
Volume mixing via jogwheeling with mouseovering. Yeah!
Check my Reaper real-time usage ideas.
boreg made it, never hanging notes in Reaper again! Thanks boreg! boreg & bang.
TonE is offline   Reply With Quote
Old 04-28-2012, 08:41 PM   #50
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 3,713
Default

Quote:
Originally Posted by TonE View Post
Then you should also know: The term "FRAND" is a FRAUD.
Ok... I know both legal terms, and I know they're *not* necessarily the same (depending on which lawyer drafted the FRAND terms, anyway, YMMV ). But you're going way OT there - I don't even see how that relates to anything I said? :/
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 04-28-2012, 08:43 PM   #51
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 3,713
Default

Quote:
Originally Posted by Banned View Post
[...] I could prepare a more extensive demonstration, I guess [...]
Ok, here's a little demonstration project (8kb .zip) for people to play with:



The mapping of OSC<-->MIDI CC# needs a bit of explanation.

Every track uses the MIDI CC# number which corresponds to the track number. Up to a 100 tracks are supported with the default setting of 100. So:
- track 1 uses CC# 1;
- track 2 uses CC# 2;
- .... and so on, until:
- track 100 uses CC# 100.

(I guess you can change the default in the OSC config file to 120 if you need a tiny bit more - at some point we run out of CC# numbers on one MIDI port x 16 channels, and would have to use multiple MIDI ports, or switch to a different mapping scheme.)

I didn't want to include only the sends, and leave out track volume and pan settings, which also can be controlled with a relatively small number of parameters. So you get those as a bonus.

I have used the CC# numbers most people are probably already familiar with for volume (7) and pan (10), for stereo width / right pan (depending on pan mode), I have used the one for balance (8).

However, and this is the important part to understand: in this case, they are not used as CC# numbers, but as MIDI channels. I have only used these numbers to make it easy to remember what function they control, not to confuse you. And since I guess most people have a much bigger number of tracks than track sends in their typical projects, while we have only 16 MIDI channels and 127 CC#s, it seemed to make sense to swap them around. Once you get this, it is not hard to figure out what MIDI channel and CC# is mapped to a particular mixer parameter.

So, for a couple of examples:
- to control the volume of track 1, you'd use MIDI CC# 1 on MIDI channel 7;
- to control the panning of track 2, you'd use CC# 2 on MIDI channel 10; and so on.
- to control the stereo width of track 3 (set to 'stereo pan' mode), you'd use CC# 3 on MIDI channel 8 (while using CC# 3 on MIDI channel 10 for the panning);
- to control the right panning of track 4 (set to 'dual pan' mode), you'd use CC# 4 on MIDI channel 8 (while using CC# 4 on MIDI channel 10 for the left panning);
- ... and so on.

Then I used MIDI channels 1 to 6 to control the volume of sends 1-6 for each individual track (i.e. the MIDI channel corresponds to the send number), and MIDI channels 11 to 16 for the panning of sends 1-6 (making it easy to remember: simply prefix a 1 before the send number) to control the panning of sends 1-6 for each individual track. So:
- to control the volume of send 1 on track 1, you'd use MIDI CC# 1 on MIDI channel 1;
- to control the volume of send 3 on track 5, you'd use MIDI CC# 5 on MIDI channel 3;
- to control the panning of send 2 on track 4, you'd use MIDI CC# 4 on MIDI channel 12;
- (NB: there are no dual / stereo pan modes available for the sends/receives in REAPER - yet; feel free to put up a FR and get my +1 vote on it ).

Taken together, using most of the MIDI CC#s on all the other 15 MIDI channels (on a single I/O port), we now have a mapping for MIDI<-->OSC conversion that maps 100 tracks x (6 x send level + 6 x pan) + volume + pan + pan2 = 1500 mapped MIDI CC#s to 1500 REAPER mixer parameters . MIDI channel 9 is still completely free to do other stuff on the same port, and you can freely use notes and such on all 16 MIDI channels, so you still have room left to control switch buttons for solo / mute / record arm / monitor and such.

The REAPER/OSC side of things is easy to set up: I have used the same UDP ports that REAPER uses as defaults for its OSC control surface support (8000/9000 - if you need to modify the port numbers, it's easy enough to find them in the Pd patch and change them), and you can use REAPER's default OSC configuration, but I have also included a 'lean and mean' configuration file in the package that ensures that only the necessary data for this example patch is sent out from REAPER to Pd. Since it is quite short and may be illustrative for those interested, I quoted it below as well (EDIT: updated with a table showing the mapping in the comments).

(I also left a few hooks for adding support for receives in the Pd patch; you'll need to decrease the number of sends and so on... Have fun. )

Let me know if you have trouble installing it or getting it to work, and I'm interested to hear how you think it compares to other possible workarounds.

Quote:
Originally Posted by OSC-MIDI-conversion-example.ReaperOSC
Code:
# [OSC-MIDI-conversion]
# OSC pattern config file for Pure data example patch;
# illustrating OSC<-->MIDI conversion for track volume + (dual) pan, 
# and volume + pan for track sends 1 through 6:
# 
#   Function:    MIDI Channel:   Track: 1 |   2  |  …  |  100
# ----------------------------------------------------------------
# Track Send 1 Volume    1  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 2 Volume    2  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 3 Volume    3  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 4 Volume    4  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 5 Volume    5  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 6 Volume    6  MIDI CC#:   1  |  2  |  …  |  100   
# Track Volume           7  MIDI CC#:   1  |  2  |  …  |  100   
# Track Pan(2)           8  MIDI CC#:   1  |  2  |  …  |  100   
# --- (NOT MAPPED) ---   9  MIDI CC#:   1  |  2  |  …  |  100   
# Track Pan             10  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 1 Pan      11  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 2 Pan      12  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 3 Pan      13  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 4 Pan      14  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 5 Pan      15  MIDI CC#:   1  |  2  |  …  |  100   
# Track Send 6 Pan      16  MIDI CC#:   1  |  2  |  …  |  100   
# ----------------------------------------------------------------

DEVICE_TRACK_COUNT 100
DEVICE_SEND_COUNT 6
# Uncomment if you want to add support for track receive volume + pan:
# DEVICE_RECEIVE_COUNT 6

# ----------------------------------------------------------------

REAPER_TRACK_FOLLOWS REAPER
DEVICE_TRACK_FOLLOWS DEVICE
DEVICE_TRACK_BANK_FOLLOWS MIXER

# ----------------------------------------------------------------

TRACK_VOLUME n/track/@/volume 
TRACK_PAN n/track/@/pan 
TRACK_PAN2 n/track/@/pan2 

TRACK_SEND_VOLUME n/track/@/send/@/volume
TRACK_SEND_PAN n/track/@/send/@/pan

# Uncomment if you want to add support for track receive volume + pan:
# TRACK_RECV_VOLUME s/track/@/recv/@/volume/str
# TRACK_RECV_PAN n/track/@/recv/@/pan
PS: note to ToneE: check inside the Pd patch, I needed much less than 1500 cables there!
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ

Last edited by Banned; 04-29-2012 at 01:37 AM.
Banned is offline   Reply With Quote
Old 04-29-2012, 03:53 AM   #52
TonE
Human being with feelings
 
Join Date: Feb 2009
Location: Midi automateable sends. Only via OSC.
Posts: 1,127
Default

Thanks Banned for sharing your solution and explanation. I will install pd-extended once again, this time considering it as an extension to Reaper, similar to sws-extension.

Regarding your example setup: Why did you use 6 sends? For what are you using so many, or did you just want to fill up the empty midi space? I was considering only 4 sends, the typical first two for reverb and delay, then another two for more crazy stuff maybe. How was your thinking?

Probably in the beginning I would also not "waste" the midi space with send-pan, but others might see it differently. Instead I would add more controls like filter, eq mainly. But probably also not compression. This would be already too special, somehow, maybe, from my point of view. Not everything needs compression anyway, imo.

In general, I liked your mapping style for simplistic mapping. For my use case I would modify it to my needs, as described in a former posting here. I am splitting the entire midi space optimized for 36 tracks use as follows, using only midi channels 1..12, keeping channels 13..16 free for other possible uses:
36 tracks are organized as three banks of 12 tracks each:
- bank0: tracks 1..12
- bank1: tracks 13..24
- bank2: tracks 25..36

Each track in a bank has its own midi channel, examples:
- bank0, track1: channel 1
...
- bank0, track12: channel 12
- bank1, track13: channel 1
...
- bank1, track24: channel 12
- bank2, track25: channel 1
...
- bank2, track36: channel 12

Each track has 40 possible parameters, which can be controlled, and are mapped as follows:
for bank = 0/1/2: cc# = 1..40 + bank * 40
In short we are using cc numbers 1..120, in groups of 40, one group for one bank. Free is also cc=0, for other possible uses.

These are the mappings for the first 36 musical tracks, excluding the sends and busses, which can be added into the free midi space. Usually the sends I would add into those "40-parameter-space" for each track, if I want sends for each track, rather than for each bus-track.
__________________
Volume mixing via jogwheeling with mouseovering. Yeah!
Check my Reaper real-time usage ideas.
boreg made it, never hanging notes in Reaper again! Thanks boreg! boreg & bang.
TonE is offline   Reply With Quote
Old 04-30-2012, 08:23 AM   #53
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 3,713
Default

Quote:
Originally Posted by TonE View Post
[...] Regarding your example setup: Why did you use 6 sends? For what are you using so many, or did you just want to fill up the empty midi space? I was considering only 4 sends, the typical first two for reverb and delay, then another two for more crazy stuff maybe. How was your thinking?
Indeed, filling up the empty MIDI space. I thought: if people stumble on this thread to find a quick hack to control sends using MIDI, better give them more rather than less.

The panning may be important for doing stuff like full-stereo impulse reverbs using a pair of ReaVerbs (tip: try a ReaVerb IR matrix using 4 stereo tracks, for separate early and late impulses as well).

Also consider for example the case of multiple musicians using headphone mixes of the other instruments that can individually be adjusted. You'd rather want to control the receives on individual tracks feeding the individual musicians' headphones, but you'd probably also want to use larger numbers of sends/receives than 2 or 4, depending on the number of musicians of course (often using a bunch of groups works well too, of course, but a musician may also like to hear the kick drum out of the drum group a bit louder than the other drums, perhaps).

So it just seemed like a sensible 'general' MIDI mapping targeted mainly at controlling sends, which seemed most appropriate for this thread.
Quote:
Originally Posted by TonE View Post
Probably in the beginning I would also not "waste" the midi space with send-pan, but others might see it differently. Instead I would add more controls like filter, eq mainly. But probably also not compression. This would be already too special, somehow, maybe, from my point of view. Not everything needs compression anyway, imo.
I couldn't agree more. This is completely different from what I'm using myself. My own method of controlling send levels is more dynamic and sophisticated, but also much more complex, and would thus not serve well as an illustrative example here. (To keep things small and simple for this example, I started from scratch and hacked it between two coffees, only reusing a few abstractions that I made earlier, iirc [mk+] for the display, and [round] which is only used to compact the layout a little bit really. But those are already 'toppings': it would also work fine as a convertor without the 'pretty' display and a bit more spaghetti on a single plate. )
Quote:
Originally Posted by TonE View Post
In general, I liked your mapping style for simplistic mapping. For my use case I would modify it to my needs, as described in a former posting here.[...]
I'll be glad to help you set up the basics of that as well. It does not seem very complex to do, but it does seem very 'personalized'. Much like mine.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 08-13-2012, 05:56 PM   #54
Indemuse
Human being with feelings
 
Indemuse's Avatar
 
Join Date: Sep 2008
Location: North Carolina, USA
Posts: 37
Default Need 64bit sender utility please?

The sender utility worked great for me in Reaper32 but I am using 64 bit now and could really use a sender util...
Indemuse is offline   Reply With Quote
Old 11-17-2012, 11:23 AM   #55
TheScientist
Human being with feelings
 
Join Date: Nov 2012
Posts: 4
Default 8 send version

is there a 16 send version ?

Last edited by TheScientist; 11-17-2012 at 11:28 AM.
TheScientist is offline   Reply With Quote
Old 02-16-2013, 03:23 PM   #56
Indemuse
Human being with feelings
 
Indemuse's Avatar
 
Join Date: Sep 2008
Location: North Carolina, USA
Posts: 37
Default Nothing here works with a hardware effects loop for live looping.

Maybe I am missing something here but I can't believe this is so difficult. For one thing - Nothing here works for 64bit (Why no 64but SendReaControl?! It was a piece of cake in 32bit...). I have a hardware effects loop running on track 1 with send going to it from my other instruments for live looping with Mobius. Everything works great but I cannot control my send levels via MIDI! What gives?
Indemuse is offline   Reply With Quote
Old 02-19-2013, 07:02 PM   #57
Indemuse
Human being with feelings
 
Indemuse's Avatar
 
Join Date: Sep 2008
Location: North Carolina, USA
Posts: 37
Default Figured Out Live FX Loop"Sends"

Ok, so I figured out using the sender utility when I want to MIDI control a send to a VST effect (Yea!) I have also figured out how to set up MIDI control for a live FX chain which I have on track 1 (Track 1 routed from Input 1 on my Presonus Firestudio Project, through an insert splitter cable to the outputs on my Digitech Timebender, then the inputs to the Timebender are routed to hardware outputs 3 & 4 on the Firestudio. In Reaper I added hardware outputs 3&4 to feed the FX.) Now, on track one I placed the JS 8 channel mixer plugin. I then simply created a send on each instrument track to the FX track and set the output channel of the send to match the mix fader in the JS plugin. Finally, I did a "Learn" on the JS plugin faders and Viola! MIDI Controllable send for a live FX chain!
Indemuse is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:18 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.