|
|
|
03-04-2012, 09:17 AM
|
#361
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Oh, I was hoping it actually is for the first instrument on a track, even if it's not in the first slot. Can someone clarify?
|
|
|
03-04-2012, 10:11 AM
|
#362
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
Quote:
Originally Posted by diversgens
Sorry to ask a probably dumb question but what's the difference between the old FX_ prefix and the new FX_INST, what is it suppose to control and when is need to use instead of FX_ ?
Thanks.
|
it will default to the first loaded vsti on a track,
so i don't think it needs to be the first plugin on the track (even though in most cases it will be)
Subz
|
|
|
03-04-2012, 10:21 AM
|
#363
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Quote:
Originally Posted by gofer
Oh, I was hoping it actually is for the first instrument on a track, even if it's not in the first slot. Can someone clarify?
|
Yes, correct. Schwa explained that here.
I haven't yet played with the new MIDI bus features, but I'm wondering if it is still valid to assume there can be only one instrument plugin in a track.
I'd like to see a plugin type message, telling whether the currently selected plugin is an effect or an instrument, or a ReWire slave. That could probably enable us to do similar things, with much less messaging.
[EDIT:] Btw, we already can parse the full plugin names to look for "VSTi: " and "AUi: " to determine the plugin is of the instrument type, so this is really just for making things easier. Thus, merely a 'nice to have, but not needed' FR.
[EDIT2:] Oh, the plugin type prefix seems to have gone in pre 25, so I should say thanks for reformatting the plugin names, much better.
Jesusonic plugins with long folder/developer names can still be problematic for smaller displays, I'd suggest placing folder/developer name behind the plugin name for Jesusonic plugins, consistent with the other types.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Last edited by Banned; 03-05-2012 at 01:22 AM.
|
|
|
03-04-2012, 10:39 AM
|
#364
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Quote:
Originally Posted by Anton9
I don't see any point in having feedback from actions.., but rather the feedback comes from what ever the action is acting upon. For example if you send /action/22 to REAPER which toggles track1 mute.., REAPER sends /track/1/mutetoggle.., that's the feedback.
|
Well then at least we agree that feedback can be useful.
The rest is perhaps more a matter of semantics, I guess. I would not say that /action/22 is acting upon /track/1/mutetoggle, but that they are synonyms, in the syntax of OSC control surface support at least (btw, imho mute is a bit too uncomplicated to serve as a good example; solo or select is a better one: e.g. selecting one track should send feedback for unselecting other tracks).
OSC control surface support simply brings to list the shortcomings of the existing actions list approach: we can bind to the actions using 'Learn', but we can not distinguish between devices [EDIT: (for MIDI bindings, we can)], and we can not get any feedback.
Now, with OSC control surface support, we can. But directly referring to the completely flat namespace of action numbers is not the optimal solution for allowing a high degree of granularity. Therefore we need a deeper namespace, such as /track/1/mutetoggle instead of /action/22. And the fact that this is also much more human readable is more than a welcome bonus. One could argue it is a sufficient reason in itself to adopt a deeper namespace.
Quote:
Originally Posted by Anton9
As for the multiple devices issue.., I think what we need are actions that toggle the state of Receive and of Send for each control surface listed.
|
That would be a good start. But I would still like a higher degree of granularity than per device on/off switching.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Last edited by Banned; 03-04-2012 at 01:34 PM.
Reason: fixed typo; added clarification
|
|
|
03-04-2012, 12:52 PM
|
#365
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Can the 'null value' be configurable please?
I'm not entirely sure, but I think I'm seeing messages from REAPER with 'blank' values in different places (e.g. /fx/@/name, /fx/@/number, where they seem to fit the general pattern that they're being used for nulling. Perhaps it is a white space being truncated, I'm not entirely sure yet.
In some cases it could be more comfortable to receive e.g. a underscore character, to more easily distinguish them from messages without a value.
How about something like:
Code:
# Default 'null' value is blank.
NULL_VALUE _
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
|
|
|
03-04-2012, 01:01 PM
|
#366
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
I think we're still missing a way to switch banks of plugins ('FX'), sends and receives.
Also, following the pattern of the similar 'actions', I'm missing
Code:
TRACK_INPUT_MONITOR_TOGGLE /track/inputmonitortoggle /track/@/inputmonitortoggle
But I still think that we should rather get rid of all *_TOGGLE 'actions' and do something more elegant to configure behavior such as choosing between toggle vs. momentary switching for control targets with binary states. So please *don't* add the 'missing' action', but think about how to do this more elegantly and efficiently.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
|
|
|
03-05-2012, 01:23 AM
|
#367
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
FR: (OSC control surface support for) mute (toggle) switches for sends and receives.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Last edited by Banned; 03-05-2012 at 01:41 AM.
|
|
|
03-05-2012, 01:34 AM
|
#368
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
I'm seeing strange numbers for the wet/dry pattern. They seem to be linked to the particular plugin parameter value, instead of plugin slot number, even though the pattern would seem to imply a slot number:
Code:
FX_WETDRY /fx/wetdry /fx/@/wetdry
E.g. with the selected plugin set to follow focus in REAPER, and ReaEQ in track 1, slot 1, I see:
Code:
/fx/14/wetdry 0.499565
/fx/14/wetdryval 49%
And with ReaEQ in slot 4 of track 2, I see:
Code:
/fx/14/wetdry 0.999954
/fx/14/wetdryval 99%
Which would rather fit the pattern ... so it seems /fx and /fxparam got mixed up by mistake somehow.
Notice also that the float value is rounded off differently for the string value display as in REAPER's GUI, where these settings correspond to 50% and 100% on the plugin GUI respectively. This should of course be made consistent, rounding to the nearest integer, as it is in REAPER's GUI.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Last edited by Banned; 03-05-2012 at 05:26 PM.
Reason: corrected with literal OSC output
|
|
|
03-05-2012, 06:28 PM
|
#369
|
Human being with feelings
Join Date: Jan 2010
Location: Paris
Posts: 234
|
GREAT!
Thank you very much for this brilliant OSC support.
Quote:
Originally Posted by schwa
We'd like to eventually support OSC sequencing, but we're starting with control-type support because that's the immediate practical application.
|
That's could be definitely awesome!
I've started a little patch within Sensomusic Usine which will be exported as win 32 app to share with Reaper users. More I progress, more I think that could be very nice to have a full control over the midi Items, and (if possible) editing them directly via OSC.
|
|
|
03-05-2012, 11:43 PM
|
#370
|
Human being with feelings
Join Date: Dec 2010
Posts: 23
|
Quote:
Originally Posted by silent
Originally Posted by schwa
We'd like to eventually support OSC sequencing, but we're starting with control-type support because that's the immediate practical application.
That's could be definitely awesome!
|
I second that! Having OSC sequencing in Reaper would be really awesome! I would use it a lot with Max/MSP and Lemur.
|
|
|
03-06-2012, 08:02 AM
|
#371
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
Quote:
Originally Posted by Banned
I think I'm seeing messages from REAPER with 'blank' values in different places
|
What you are seeing is probably empty strings, which is valid data. An empty string should be sent as OSC argument type 's', with four nulls for the string value.
|
|
|
03-06-2012, 09:32 AM
|
#372
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
4.16pre26 has a complete overhaul of how the pattern config files work. Unfortunately this means all custom pattern config files created before pre26 will need to be rewritten.
There may also be new bugs caused by the changes, so please let us know if anything that worked previously stops working!
|
|
|
03-06-2012, 11:04 AM
|
#373
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
having trouble making reaper select a track from the OSC device?
any tips?
Subz
|
|
|
03-06-2012, 11:15 AM
|
#374
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
Quote:
Originally Posted by Subz
having trouble making reaper select a track from the OSC device?
|
You want the old behavior back, where the DEVICE_PREV_TRACK and DEVICE_NEXT_TRACK actions cause the track selection in REAPER to change? I suppose we can add an option for that.
|
|
|
03-06-2012, 11:22 AM
|
#375
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
Quote:
Originally Posted by schwa
You want the old behavior back, where the DEVICE_PREV_TRACK and DEVICE_NEXT_TRACK actions cause the track selection in REAPER to change? I suppose we can add an option for that.
|
Yes Please!!!
option is defo better!
but if i'm in the booth & record one track i want to simply select the next track & hit record again (as i use auto record arm & track selection mostly to set recording tracks)
Subz
|
|
|
03-06-2012, 12:02 PM
|
#376
|
Human being with feelings
Join Date: Jun 2008
Location: Whales, UK
Posts: 6,010
|
way to give a bunch of homework sorting out configs!
seriously, the new flag changes makes sense in the long run though, all good.
though as above i'm for opening (literally.. potential flood) gates rather than closing them.
EDIT: question - how should one format the pattern from the XY pad of sayy touchosc?? two values get received by reaper, but getting reaper to do two things with them i've not quite fathomed. it's possibly the last little piece in the jigsaw for me, never sure if its reaper config related or how to form the pattern from device. any clue appreciated, and i won't ask anymore questions.
Last edited by BenK-msx; 03-06-2012 at 12:07 PM.
|
|
|
03-06-2012, 12:31 PM
|
#377
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
Quote:
Originally Posted by BenK-msx
how should one format the pattern from the XY pad of sayy touchosc?
|
You can use the multiparameter patterns for this. If you configure the XY pad send something like /fxparam/1,2 it will simultaneously set parameters 1 and 2 for the current selected FX. Unfortunately touchosc isn't sophisticated enough to do anything too useful, like changing which parameters get targeted at run-time.
|
|
|
03-06-2012, 12:35 PM
|
#378
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
Quote:
Originally Posted by Subz
we seem to have lost "LAST_TOUCHED_FX_PARAM_VALUE_STRING" in this update?
|
See the default config file. You can now make patterns like this:
Code:
LAST_TOUCHED_FX_PARAM_VALUE n/fxparam/last_touched/value s/fxparam/last_touched/value/str
Which will send a normalized (0-1) value for the first pattern, and a string value for the second pattern.
|
|
|
03-06-2012, 12:38 PM
|
#379
|
Human being with feelings
Join Date: Jun 2008
Location: Whales, UK
Posts: 6,010
|
Quote:
Originally Posted by schwa
spoketh
|
thankyou v much
|
|
|
03-06-2012, 12:49 PM
|
#380
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
need a bit of help on how to replace "FX_PARAM_PAGE_NUMBER"
this is also not working in the logictouch preset
Subz
|
|
|
03-06-2012, 12:52 PM
|
#381
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
Quote:
Originally Posted by Subz
need a bit of help on how to replace "FX_PARAM_PAGE_NUMBER"
|
There's a typo in the packaged LogicTouch.ReaperOSC file. The line should be:
Code:
DEVICE_FX_PARAM_BANK_SELECT s/2/page#
|
|
|
03-06-2012, 01:00 PM
|
#382
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
Quote:
Originally Posted by schwa
There's a typo in the packaged LogicTouch.ReaperOSC file. The line should be:
Code:
DEVICE_FX_PARAM_BANK_SELECT s/2/page#
|
cheers buddy!
Subz
|
|
|
03-06-2012, 01:38 PM
|
#383
|
Human being with feelings
Join Date: Jun 2008
Location: Whales, UK
Posts: 6,010
|
Mr Schwa, XY pad work great for track volumes..:
eg 1/volume/1,2
however fx paramater are working odd, i can only successfully control params on the 1st track of master (as is the fashion)
this goes for plain sliders too.
eg for a test i set:
DEVICE_FX_FOLLOWS_FOCUSED n/yo
and sending from device /yo/fxparam/N
device only controls param N of 1st fx on master, no matter what is selected or focused.
Last edited by BenK-msx; 03-06-2012 at 01:44 PM.
|
|
|
03-06-2012, 01:52 PM
|
#384
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Quote:
Originally Posted by schwa
4.16pre26 has a complete overhaul of how the pattern config files work.
|
Thank you! I haven't started to test it yet, but it already makes so much more sense now just reading through the config file and comments. I really think this should improve both the learning curve of new users and the power of the feature set for more advanced users. Excellent!
I do have a bit of doubt about the syntax - I just wonder if it may be confusing to have the flag prefixed onto the OSC address pattern. But that is of minor importance, I could only suggest arbitrary alternatives, and imho only completely new users are able to pass a decent judgement on the question whether it is easy to understand. What counts is that it is easy enough to understand and configure, yet powerful. This approach seems to fit that bill well enough.
Btw, another detail: I like how "volume" is now used consistently throughout (instead of volume / level).
Quote:
Originally Posted by schwa
Unfortunately this means all custom pattern config files created before pre26 will need to be rewritten.
There may also be new bugs caused by the changes, so please let us know if anything that worked previously stops working!
|
That is what pre-releases are for. I'm sure we'll get it all working as before, or better.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
|
|
|
03-06-2012, 02:45 PM
|
#385
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Quote:
Originally Posted by schwa
You want the old behavior back, where the DEVICE_PREV_TRACK and DEVICE_NEXT_TRACK actions cause the track selection in REAPER to change? I suppose we can add an option for that.
|
Yes, it should be an option. The behavior was awesome in the simple case - you're controlling REAPER from a single device, as a single user, but it was undefined and uncontrollable, so undesirable effects in corner cases could not be prevented.
It should probably default to off, while we think of something for those corner cases (Should it be exclusive, i.e. for one device at one time only? Who decides? Warn the user when another device is also setting the track selection in REAPER? Can the REAPER user override exclusive control from devices? Etc.). Preferably after getting some input from different users that have had some practical experience with scenario's such as one person using a computer running REAPER (i.e. recording engineer), who is recording a couple of musicians that are all using remote controllers controlling some aspects of REAPER as well. I can do some testing with multiple devices, but e.g. recording sessions with multiple persons operating remote control devices are definitely not my daily workflow, but I can easily imagine they will become important to many REAPER users.
Since it could easily be confused for the feature where the device track selection follows the track selection in REAPER (i.e. the other way around), we should pick a really unambiguous name.
---
I also (still) think it would be useful to be able to have TRACK_NUMBER (and the other *_NUMBER patterns) both send and receive (to skip directly to a non-adjacent track, etc.) integer values. It looks quite weird to use a string for something that can only take an integer number as a value, so I'm also wondering what explains this particular design choice?
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
|
|
|
03-06-2012, 03:19 PM
|
#386
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
TRACK_NUMBER and FX_NUMBER are just for display (for example, when the device is listing a bank of tracks). You can use an integer argument to DEVICE_TRACK_SELECT, DEVICE_FX_SELECT, etc to jump directly to another track/fx/etc.
|
|
|
03-06-2012, 04:27 PM
|
#387
|
Human being with feelings
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
|
Quote:
Originally Posted by schwa
What you are seeing is probably empty strings, which is valid data. An empty string should be sent as OSC argument type 's', with four nulls for the string value.
|
Thanks for the clarification.
It doesn't change the status of my FR though; I'd still like to be able to configure it to take another value for some scenario's. Purely as a "nice to have", very low priority thing to more easily suit personal preferences for how thinks look when used to create a GUI on a control surface. (Much like the plugin name reformatting, but even less important; it can also be handled easily at the client end).
I am now seeing another null value (default config, pre 26), but this one seems to be a bug:
Code:
/track/volume/str -22.6dB
/track/volume 0.33
/track/1/volume/str -22.6dB
/track/1/volume 0.33
/track/volume/db/str -22.6
/track/volume/db
/track/1/volume/db/str -22.6
/track/1/volume/db
It seems to be missing the float value for the pattern:
Code:
TRACK_VOLUME_DB f/track/volume/db f/track/@/volume/db
(BTW: very nice surprise to see a pattern for the dB value without the dB suffix as well, also allowed me to toss out some reformatting code for tiny displays on the client side. )
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
|
|
|
03-06-2012, 06:54 PM
|
#388
|
Human being with feelings
Join Date: Jan 2010
Location: Paris
Posts: 234
|
reaOSC Patch GUI
I've started this project within Usine but I'd be great to do a multi-platform build,
so I'm looking for a simple & free C++ OSC library...
Currently I've found OpenFramworks + ofxOSC Addons which seems to be quite easy to implement. But I would like some pro advises
|
|
|
03-06-2012, 07:43 PM
|
#389
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
Quote:
Originally Posted by silent
so I'm looking for a simple & free C++ OSC library...
|
Looks like an interesting project!
I like the looks of this OSC library: http://gruntthepeon.free.fr/oscpkt/
OSC is quite simple, as you can see from that tiny implementation.
|
|
|
03-06-2012, 08:04 PM
|
#390
|
Human being with feelings
Join Date: Jan 2010
Location: Paris
Posts: 234
|
Thanks, That's exactly what I was looking for. simple and efficient!
|
|
|
03-06-2012, 08:42 PM
|
#391
|
Human being with feelings
Join Date: Jun 2009
Location: South, UK
Posts: 14,218
|
that would look great on my android!
|
|
|
03-07-2012, 03:11 AM
|
#392
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
Quote:
Originally Posted by silent
I've started this project within Usine but I'd be great to do a multi-platform build,
so I'm looking for a simple & free C++ OSC library...
Currently I've found OpenFramworks + ofxOSC Addons which seems to be quite easy to implement. But I would like some pro advises
|
WTF!
will that load on a Android? (Tablet) or computer only?
Subz
|
|
|
03-07-2012, 03:29 AM
|
#393
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
here is a bug with the string for FX Params on OSC devices
https://www.youtube.com/watch?v=N8lIeQc0s5I
its the same one you fixed with last touched parameter strings,
the one where the string would display on the osc device fine when moving the parameter from reaper with the mouse but would vanish when you used the osc device to move the parameter
if my explanation confused as much as it confused me just watch the video
Subz
|
|
|
03-07-2012, 03:46 AM
|
#394
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
i cant get this to work?
DEVICE_FX_FOLLOWS DEVICE
DEVICE_FX_FOLLOWS_LAST_TOUCHED t/2
DEVICE_FX_FOLLOWS_FOCUSED t/4
page /2 & page /4 should switch my DEVICE_FX_FOLLOWS but its not working, (was working in pre25 OSC)
am i doing something wrong or is it a bug?
Subz
Last edited by Subz; 03-07-2012 at 04:39 AM.
|
|
|
03-07-2012, 05:13 AM
|
#395
|
Human being with feelings
Join Date: Mar 2010
Location: Newcastle - UK
Posts: 567
|
Quote:
Originally Posted by Subz
WTF!
will that load on a Android? (Tablet) or computer only?
Subz
|
Patience Windows 8 Tablets will be around soon
But TBH I'd rather have it on Android.
|
|
|
03-07-2012, 05:16 AM
|
#396
|
Human being with feelings
Join Date: Jun 2009
Location: Earth
Posts: 1,340
|
/time Bugs
Here are a few bugs I encountered when using /time and /time/str.
Bug-1:
With the ruler set to "Seconds" and zoomed all the way in when I send "time",1.002 as can be seen in this pic, the cursor doesn't get set to 1.002
Bug-2:
time/str doesn't work correctly when the ruler is set to "Samples", in this pic I sent "/time/str", 44200 and it put the cursor at 1949220000 as can be seen in this pic.
Bug-3:
time/str also doesn't work correctly when the ruler is set to "Hours:Minuets:Seconds:Frames" as can be seen in this LICEcap.
|
|
|
03-07-2012, 05:33 AM
|
#397
|
Human being with feelings
Join Date: Jun 2009
Location: Earth
Posts: 1,340
|
Scrub Request
Schwa,
It would be nice if we could have a Scrub pattern that works bi-directionally like "/time" does when it is assigned to a slider.
In other words it work exactly like "/time" but it would scrub.
By the way thank you for fixing the the "Remove" function of learned OSC messages.., and for allowing multiple parameters to be learned to the same /message.
|
|
|
03-07-2012, 05:38 AM
|
#398
|
Human being with feelings
Join Date: Jun 2009
Location: Earth
Posts: 1,340
|
One other little bug
Schwa,
Still unable to set the tempo above 296 when using "tempo/raw".
|
|
|
03-07-2012, 06:36 AM
|
#399
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
OSC Pan & Mute is not updated on device if you change it from a midi controller, using mouse updates OSC device fine!
Subz
|
|
|
03-07-2012, 07:35 AM
|
#400
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,822
|
Quote:
Originally Posted by Subz
here is a bug with the string for FX Params on OSC devices
|
I can't reproduce that. Does it happen with any FX (including Cockos FX)? If so could you copy the .reaperosc file here?
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:45 AM.
|