anyone on windows tablet?
-
Heres the 2012 docs http://www.sws-extension.org/download/S&M_LiveConfigs_Ed2.pdf
We're kind of using it only as an action loader, not much else. I'm seeing if there is any way to assign the rows individually through different messages than different values of the same CC...it has been a pain making that setup work
-
Yeah I have that installed.
The way I have been able to work with it is to save tracks in line with it but then you'd have to save the whole project and then load the project to make it work right? It doesn't actually save parameters or presets right?
-
I'm not positive, I save it by project. Let me see if I can export enough junk into a zip file for you to test. The template I'm using is using a free VST wah called NSP Wahman, and one of mschnell's JSFX can make it auto engage!
-
Oh that's awesome!
I'm not a big way guy myself.. figure if I really needed one I could just slap my crybaby in front of the interface yeah?
-
I actually need a VST for the EHx POG lol
-
I never owned a wah, but I figured since I have been bugging PG like hell to make their wah autoengage, I better make my setup work it!
-
Ok, if you are glutton enough to try this, back up your configs, then import this to your configs and run the rpp. I havent stripped the third party plugs out of this, but I will for a real template. The required plugs and scripts for the templates to work will be provided on ReaPack once we figure out what those are exactly
https://www.dropbox.com/s/urfm8l5ztv31v67/REAPER Live - Fadescript no spillover.zip?dl=0
-
And you think this will give better performance than gigperformer? Or I guess your way makes it a free add on to what we already have
-
Its different, it won't get the temporary volume spike of gig performer, and the figuring scripts MIGHT be easier since there are so many scripters around. I am seeing much lower CPU use in this than gig performer, but the RT CPU use seems to be about the same, which is the parameter that counts
-
Gig Performer has a LOT of advantages going for it, so I wouldn't say its a direct replacement. I'm planning on learning a lot more of Gig Performer scripting to see if its not the better route to go in the end. If I had enough coding skills, I'm pretty sure either one could do the exact same things
-
Crap, I forgot the command to reset the wah on patch change....working on it
-
yeah i would rather work with reaper as its the most familiar to me.
My real goal is to use this like different rigs right?
like it will be great to have tracks to switch between but i am thinking it more of what I would use to perform live.
Im going to want to switch fx on and off.
Question: What makes more sense?
Having one signal chain with the pedals and amp you like and turning them on and off.
or
Having a different track set up for every setting you would want to switch to i.e: one track with tubescreamer on. one track with tubescreamer off. one track with this channel of the amp. one track with the other channel of the amp. one track with delays on and one track with delays off.....and then just switching the tracks instead of turning fx on and off.
What do you think is the better way to do it?
Im completely beyond bias at this point FYI. I am using different VSTs from all different companies. Check out Valhalla if you havent. man that is one amazing set of reverb/delay plujgs
-
While I was working on this, patches, vs stomp switching vs loop switching in many ways, became a distinction without a difference. If switching could be made just as fast from patch to patch as stomp switching, we really lose any real distinction. In this template there, pedal 2 and pedal 3 are just like switching a tube screamer in and out of pedal 2, except that I also have some things happen to make up for the tonal and volume differences involved. The way SWS stuff works, loop switching is tricky. Stomp toggling CAN be tricky, but you are always also free to use that track's internal FX CC controllable functions as well...it can get insanely complicated, but if you can think up what paths you want, there are ways to get there. My big concern #1 is resource use, I don;t ever want a situation where a computation takes more time than the output buffer allows (view/ performance meter, enable RT Longest Block), switching time dropout and spillover
-
Ok, this is updated to put the wah on bypass on patch changes and now includes one project file with and one project file without some spillover fx
https://www.dropbox.com/s/u7cs0tdptwbjkuf/REAPER Live Fadescript.zip?dl=0
-
Here's an updated version using this morning's new "Midi Fader X" JSFX plugin. ABout to try it on the craptop in a second, running fine on the desktop. https://www.dropbox.com/s/koyqlzt8o6sqzbs/REAPER Live MFX 2-15-2018.zip?dl=0
-
Here we go, running on the crappy craptop! https://www.instagram.com/p/BfPOYFohwKg/?taken-by=pipelineaudio
-
@pipelineaudio said in anyone on windows tablet?:
Here we go, running on the crappy craptop! https://www.instagram.com/p/BfPOYFohwKg/?taken-by=pipelineaudio
Unfortunately my testings with a small but weak Eee PC 1005HA (Seashell with an Intel N280 (1,66 GHz)) where not successful on BIAS Standalone. It was nearby but crackling at a CPU usage of 98%. I would have loved to use this Netbook but it was worth a try ;)
-
@sascha-ballweg said in anyone on windows tablet?:
Intel N280
Ahh bummer....Not too terribly surprised that the ATOMS might not do it, but it would have been nice!
-
@pipelineaudio my biggest concern is using too much CPU by having all these different tracks loaded with 4-5 instances of the same plugins. do they not take CPU if the track isnt armed?
-
@pipelineaudio said in anyone on windows tablet?:
While I was working on this, patches, vs stomp switching vs loop switching in many ways, became a distinction without a difference. If switching could be made just as fast from patch to patch as stomp switching, we really lose any real distinction. In this template there, pedal 2 and pedal 3 are just like switching a tube screamer in and out of pedal 2, except that I also have some things happen to make up for the tonal and volume differences involved. The way SWS stuff works, loop switching is tricky. Stomp toggling CAN be tricky, but you are always also free to use that track's internal FX CC controllable functions as well...it can get insanely complicated, but if you can think up what paths you want, there are ways to get there. My big concern #1 is resource use, I don;t ever want a situation where a computation takes more time than the output buffer allows (view/ performance meter, enable RT Longest Block), switching time dropout and spillover
gtrr meant to reply to this. my concern would be using too much CPU.
right now the code on my midi controller works like this
mode one sends CC codes 60:61:62:63:64 and then if I hold down a switch for 2 seconds it changes to 80:81:82:83:84
so I can have 4 more different banks too.
Preset Switching
So I essentially could have 5 tracks in the first bank. Mode 1 will use the live configs to arm the track i wantI can load up a specific set of switches when i load the preset so I could load Preset 60 and then the switches change to 1:2:3:4:5 for the stomps.
Then I can have it set so that when I pick code 61 it will send 61 to SWS but also load my controller with 6:7:8:9:10 that I can use as stomp codes for patch 61.
Does that make sense?
this is amazingly configurable if possible using just a cheap custom coded 5 switch box