How should profile / input link for the OSSC work?

[borti4938]

I'm quite unsatisfied on how the current implementation is. For me it has some drawbacks or in other words it does not works as expected. This is how I understand the term profile / input link:

• If I change the input, I expect the last profile used for that input to be load. -> OK, that works!
• If I change the profile, I expect the input to be load, which I used for setting up the profile. -> This does not work / is not possible in the current implementation.

Furthermore I expect next to the profile / input link:

• If I power cycle the OSSC, I expect the last input I load. But this not the case; the default input will be load. Furthermore the default input is a global setting since last firmware (v0.80) and not the setting connected to a profile.

A quite large drawback for me as I don't want to change and save global default input setting every time I need to. (E.g. when playing some days a console on AV2 and afterwards some days on a console connected to AV1)

Maybe it's just a personal flavour, but I'm used to use the default input on each profile to switch between inputs. This is something I implemented quite early for me. But this needs default input for each profile.

So let's the discussion start:
What's your flavour? How do you expect profile / input link to be work (one-way vs. two-way)? Do you have another intention how profile and input handling should work?

Please also use the poll. Each user has two options. Please use one tick to make a choice between the "O1"s and one tick for the "O2"s.

[ASDR]

Some very interesting points, haven't really made up my mind how I'd want this to work ideally.

IIRC, wasn't automatic input switching already implemented by somebody? Guess it didn't make it into the last FW update. Wouldn't that feature reduce the need to associate an input with a profile? You just load up the profile for your console and turn it on, no need for the profile to switch inputs and no extra button presses either.

One bit of wishful thinking I had regarding profiles was that maybe the OSSC could actually recognize each console automatically and load up its associated profile. For instance, a SNES is 60.08Hz, a PCE is 60.28Hz, etc. Maybe that would already be enough to distinguish most consoles. There's perhaps other aspects usable for fingerprinting, maybe each system has something distinct and easily recognized about its sync pulses. Different machines also have different video modes and/or overscan. For instance the PCE seems to fill out the frame almost completely, 3D Saturn games always have quite large borders, SNES has borders, but less so etc. Would be absolutely amazing if the OSSC came with a selection of FBX profiles and would just automatically chose the right one

[borti4938]

Auto input switching was consuming to much code space in its suggested implementation. However,
a) it's independent on the stuff here. You need to have a initial point. And
b) If the OSSC auto switches on boot, you want to have the profile appropriately switched, or not?

The other points are also interesting, but that's also another point, where you or your OSSC got the profiles from. At the moment even import from SD is not possible. To have the preset profiles for certain consoles somehow build in by firmware (e.g. in the flash unit right after firmware image) could be imaginable; this needs someone who creates and polish them for config changes. But also somehow indepent of what I think where the discussion should go to.

[Fudoh]

* If I change the profile, I expect the input to be load, which I used for setting up the profile.

I would find this confusing, unless we would start naming the profiles beginning with the input (e.g. AV1-P01) and add an clear additional option to copy profiles over from one port to another.

I mean the MAIN use of profiles is that somebody uses different sources on the same input..., but once you tuned an option (e.g. the sampling options) you might want to copy it to a different port for use with another (or the same) system. Imagine this situation: you have profile 1 setup and runninga and you know that's your PS1 profile with tweaked 320x240 sampling. Now you have your PS2 running on the YUV input and you want to enable that profile because you're using a PS1 game. If choosing the same profile throws you back on AV1 at the same time, it could potentially drive you crazy.

* If I power cycle the OSSC, I expect the last input I load. But this not the case; the default input will be load. Furthermore the default input is a global setting since last firmware (v0.80) and not the setting connected to a profile.

I'm with you on this. Defaulting to the last used input would be good. Tying this to a profile is not a good idea though - it's completely contrary to your options above. You wouldn't want a default port linked to a profile that's linked to a specific input after all ?!

Does the main screen currently indicate that a profile is in use ? Can't remember right now. MAybe we could introduce something like an asterisk next to the input name to indicate that a specific profile is in use and that any changes done at the moment are done to that profile.

(and while not related to this, but to your recent beta FW (I think): we need an option for that display timeout. I can't stand it, but I understand that some people might like it).

[rama]

I don't own an OSSC but I have a similar situation on my GBS project.
On mine, I detect the AV port on which a sync signal is present and switch to that input.
If none of the inputs has a signal, I keep the display turned off and keep looking for sync, until I get something.

Does the OSSC do a similar thing?
This does solve the issue of determining which input it should start on.
If people connect 2 active devices to the GBS, I blame them for doing something stupid ;p

[ASDR]

Auto input switching was consuming to much code space in its suggested implementation. However,
a) it's independent on the stuff here. You need to have a initial point. And
b) If the OSSC auto switches on boot, you want to have the profile appropriately switched, or not?

The other points are also interesting, but that's also another point, where you or your OSSC got the profiles from. At the moment even import from SD is not possible. To have the preset profiles for certain consoles somehow build in by firmware (e.g. in the flash unit right after firmware image) could be imaginable; this needs someone who creates and polish them for config changes. But also somehow indepent of what I think where the discussion should go to.

I think the two features I brought up address the same problem.

If the OSSC could auto switch to an active input, I wouldn't need to associate an input with a profile. I'd just load up the profile I want and the input would take care of itself.

Detecting a console from its video signal is useful totally independent of importing profiles or having well-calibrated stock ones. If I could associate a profile with a console, I wouldn't need to associate inputs with profiles or profiles with inputs.

I didn't want to hijack your thread, but if we had automatic switching of inputs and the ability to associate a profile with a console the question of linking profiles & inputs in either or both ways would not even come up. I just turn on my console and the OSSC would automatically switch to that input, detect what device it is and loads its profile.

That's probably two steps ahead and perhaps wishful thinking, though, so I'll shut up now

[borti4938]

* If I change the profile, I expect the input to be load, which I used for setting up the profile.

I would find this confusing, unless we would start naming the profiles beginning with the input (e.g. AV1-P01) and add an clear additional option to copy profiles over from one port to another.

I mean the MAIN use of profiles is that somebody uses different sources on the same input..., but once you tuned an option (e.g. the sampling options) you might want to copy it to a different port for use with another (or the same) system.

I don't get your point why find this confusing. I dedicate also each profile to a console. And a single console is just connected to a single input. So, if I want to play e.g. SNES I load profile 1 and expect AV1: RGBS active afterwards. This does not happens unless it was active beforehand. So I have to switch to AV1 first and then load profile 1 if profile 1 was not the last profile saved on AV1: RGBS. And this annoys me atm.

Of course, having a profile on AV1 and want to reuse it on AV2 is a special case but a copy profile option could help.

I'm with you on this. Defaulting to the last used input would be good. Tying this to a profile is not a good idea though - it's completely contrary to your options above. You wouldn't want a default port linked to a profile that's linked to a specific input after all ?!

I don't see why this is contrary. You start with last input and last profile use. There is no cause to prefer something different in my point of view.

I guess you didn't fully got me. Profile link (also as it is implemented atm) just remembers which profile you lastly loaded/saved on a active input. This will not be changed.

By loading a profile I want to switch the input, too. This process updates the last last profile for the now used input.

Its somehow redundant.

Example:
- Profile 1 lastly used on AV1:RGBS
- Profile 1, 3 and 4 have setup for AV1: RGBS
- Active input AV2:RGsB

So what to do if I want to play AV1:RGBS with profile 3.

Current implementation
- switching directly to AV1:RGBS loads profile 1 automatically
- loading to profile 3 instead does not switches to AV1:RGBS;
- so loading profile 3 before switching input to AV1:RGBS forces you to load profile 3 again as once you switched to AV1:RGBS it loads profile 1 again

Suggested implementation:
- switching directly to AV1:RGBS loads profile 1 automatically
- loading to profile 3 switches also to AV1:RGBS with profile 3 active (and updates that on AV1:RGBS was profile 3 lastly used)
- loading profile 3 after switching to AV1:RGBS does not hurt as you stay in profile 3

(and while not related to this, but to your recent beta FW (I think): we need an option for that display timeout. I can't stand it, but I understand that some people might like it).

[/quote]
(It's not part of the official firmware and won't be. The logic is hard coded in HDL. Also I did it for me... So I don't care as I tweak it for my needs to not use any sw code space. If someone want to have it different, he can just copy the source and tweak it for his needs )

[marqs]

There are clearly many different usage scenarios of which all were not foreseen when profile link option was originally developed. My suggestion is to add a new option instead of changing funcitonality of the current ones. With that, the following 3 options would control profile/input selection logic:

* Initial input (global)
Selects power-on input. "Last Used" can be used if user prefers to auto-select the input which was last active

* Link input/prof (global)
Links profile to input

* Auto-change input (NEW, profile-specific)
values: "none, last used, AV1: RGBS, ... , AV3: YPbPr"
Changes input when profile is loaded. This would enable automatic input change whenever a profile is loaded manually

[neorichieb1971]

I don't have an OSSC yet and I don't know how it works or whatever.

But if I was implementing this setup I would create a menu called "Assignment preferences" or something similar.

On the left it states AV inputs

AV1
AV2
AV3

On the right it pulls up a dropdown menu of profiles stored.


So the menu might read something like -

AV1 - SNES
AV2 - PS2
AV3 - Dreamcast

So unless you change the profile attached to the AV input, it stays so. You still need to toggle inputs.

If the hz timings are specific to a console and you can get the OSSC to automatically read the consoles signature that would be even better.

[nmalinoski]

Suggested implementation:
- switching directly to AV1:RGBS loads profile 1 automatically
- loading to profile 3 switches also to AV1:RGBS with profile 3 active (and updates that on AV1:RGBS was profile 3 lastly used)
- loading profile 3 after switching to AV1:RGBS does not hurt as you stay in profile 3

So how would this work with a PS2 switching between RGBS and RGsB? If you change input to RGsB, that could end up loading a different profile, and if you try loading the PS2 profile again, that would just switch input back to RGBS. So, what, we'd need two PS2 profiles in this scheme?

I kind of like the idea of associating a default profile for a given input, but I'm not sure I think it would always be appropriate for a profile change to also change input. I may have six or more consoles connected via an AV switch to a given input at one time, all potentially needing their own profile. I really don't want to have to configure all that, especially knowing all the work I put into that is going to be wiped out during the next firmware update.

For me, I'd want the OSSC to do an automatic input switch, perhaps loading a default profile for the resulting input, and then I can change profiles manually with the remote if I need something special.

Detecting a console from its video signal is useful totally independent of importing profiles or having well-calibrated stock ones. If I could associate a profile with a console, I wouldn't need to associate inputs with profiles or profiles with inputs.

The "easy" way of associating a profile with a console would be if the OSSC could interface with switches, then you could more easily associate a profile directly with a specific console. (And potentially remote-control the switch; gscart/gcomp switches have interface headers, and pro gear like Extron and Kramer switches have RS232 serial control.) borti's desire for switching inputs with a profile change makes way more sense to me with this kind of setup.

For example, if I turn on my Xbox, connected via YPbPr to a gcompsw that the OSSC is interfaced with, the OSSC could detect precisely which input is connected on which switch, change its input to that, and load a very specific profile, all automatically.

Though those with PS2s connected via SCART might still want some level of automatic switching of input without automatic switching of profile to handle the RGBS<->RGsB transitions.

[borti4938]

So how would this work with a PS2 switching between RGBS and RGsB? If you change input to RGsB, that could end up loading a different profile, ...

This is how the link works atm anyway...

... So, what, we'd need two PS2 profiles in this scheme?

In my suggested way, yes. But do you really use sometimes PS2 in RGBS and sometimes in RGsB? To be honest, I don't see the reason for that. But I don't have a PS2, so please explain me why one or the PS2 do that?

A copy function would be helpful in that case as Fudoh suggested anyway: https://github.com/borti4938/ossc/commi ... 717cea0d11

I kind of like the idea of associating a default profile for a given input, but I'm not sure I think it would always be appropriate for a profile change to also change input. I may have six or more consoles connected via an AV switch to a given input at one time, all potentially needing their own profile. I really don't want to have to configure all that, especially knowing all the work I put into that is going to be wiped out during the next firmware update.

My suggestion / idea does NOT mean, that you only have a single profile for each input. You'll still have ten profiles and can dedicate e.g. six of them or all ten to AV1.

[ASDR]

Detecting a console from its video signal is useful totally independent of importing profiles or having well-calibrated stock ones. If I could associate a profile with a console, I wouldn't need to associate inputs with profiles or profiles with inputs.

The "easy" way of associating a profile with a console would be if the OSSC could interface with switches, then you could more easily associate a profile directly with a specific console. (And potentially remote-control the switch; gscart/gcomp switches have interface headers, and pro gear like Extron and Kramer switches have RS232 serial control.) borti's desire for switching inputs with a profile change makes way more sense to me with this kind of setup.

For example, if I turn on my Xbox, connected via YPbPr to a gcompsw that the OSSC is interfaced with, the OSSC could detect precisely which input is connected on which switch, change its input to that, and load a very specific profile, all automatically.

Though those with PS2s connected via SCART might still want some level of automatic switching of input without automatic switching of profile to handle the RGBS<->RGsB transitions.

Yeah, when I saw that superg's switches have an external control interface I was already thinking it's probably quite easy to make a little Arduino weekend project that sends an IR command to the OSSC for loading up a profile whenever the switch selects a different input. Not sure if his switches have only external control or if they also can be polled for the current state.

If device detection could be done purely in software that would be perfect, though. No extra hardware or special switches required. Not sure how feasible that is. Refresh rate could be one point, there might be other signal timings etc. that make for even better fingerprinting of the device.

Automatic switching of inputs seems like a natural complement to this feature. Too bad the patch couldn't be merged. From what I remember it was simply quickly switching between the inputs and watching for sync, that couldn't have been too many instructions. Memory situation seems dire

[nmalinoski]

... So, what, we'd need two PS2 profiles in this scheme?

In my suggested way, yes. But do you really use sometimes PS2 in RGBS and sometimes in RGsB? To be honest, I don't see the reason for that. But I don't have a PS2, so please explain me why one or the PS2 do that?

To answer your second question, as I understand it, when using an unmodded PS2 with Component Video set to RGB, it will use RGBS (sync on composite or luma, depending on cable) for 240p/288p/480i/576i (so, most content), but it will switch to RGsB for games that support 480p/576p/720p/1080i. I'm not sure whether this is was to prevent damage to CRTs that couldn't handle 480p and up, or if it was just because Sony really liked Sync-on-Green, but that's the reality of the PS2.

To answer your first question, no, I don't use my PS2 in RGB mode or SCART cables; I just use the official component cables and have Component Video set to YPbPr. I'm in the US, so RGB was never really an option for me, and, these days, I find it's much more straightforward to use YPbPr component over trying to deal with the RGBS/RGsB switching, especially in conjunction with devices that don't support RGsB, like the gscartsw; but I certainly don't represent the majority of PS2 owners.

That said, citrus3000psi has written guides on how to mod the PS2 to always output RGBS with composite sync, which would eliminate the sync-on-green issue altogether, but not everyone's going to want to do that or be comfortable performing that kind of mod.

[borti4938]

Thank you for picking thank you for picking me up

[nmalinoski]

Yeah, when I saw that superg's switches have an external control interface I was already thinking it's probably quite easy to make a little Arduino weekend project that sends an IR command to the OSSC for loading up a profile whenever the switch selects a different input. Not sure if his switches have only external control or if they also can be polled for the current state.

If device detection could be done purely in software that would be perfect, though. No extra hardware or special switches required. Not sure how feasible that is. Refresh rate could be one point, there might be other signal timings etc. that make for even better fingerprinting of the device.

According to superg's website, all of his switches support querying for the enabled input through the EXT header, and the gscartsw_lite and gcompsw additionally support overriding input. Unfortunately, I haven't seen superg actually publish any documentation for this interface; only vaguely describing the available pins (I'm not sure anyone has directly asked him for the pinout).

So, if you were to get the pinout(s), solder on a block of header pins, and run a cable from the switch to an Arduino, RasPi, BeagleBone, or whatever, you could do as you described. Hopefully there's a way to hook up 3 or 4 (possibly more) of these switches, because I know there are people who daisy-chain their gscart and gcomp switches; would probably be a hell of a lot simpler if the EXT header used something like i2c. (Maybe little i2c modules can be built to interface with EXT instead of directly?)

Taking this a step further (and a step further off-topic; I'm sorry, borti), since we're talking about remote-controlling the OSSC with an IR blaster, if you were to use something like a RasPi Zero W instead (something with both GPIO and networking that can run a web server), you could [relatively] easily build a web UI to not only configure your profile-to-input associations, but also build your profiles, and then automatically reconfigure the OSSC. Hell; if you could hook up to the OSSC's JTAG port, you could, theoretically, remotely install firmware updates. And, since it's all remote and automatic, you could hide everything in a cabinet somewhere.

[orange808]

I don't want profiles associated with inputs at all. When I load a profile, I want to import saved settings for everything but the input.

When I load a profile, I want the current input to use the settings I loaded. If I change the input, I don't want the machine to guess what kind of output I want. I'll load a new profile or dive into the settings and decide.

I also want the option to keep booting to a test pattern. I'll choose the input.

[ASDR]

According to superg's website, all of his switches support querying for the enabled input through the EXT header, and the gscartsw_lite and gcompsw additionally support overriding input. Unfortunately, I haven't seen superg actually publish any documentation for this interface; only vaguely describing the available pins (I'm not sure anyone has directly asked him for the pinout).

So, if you were to get the pinout(s), solder on a block of header pins, and run a cable from the switch to an Arduino, RasPi, BeagleBone, or whatever, you could do as you described. Hopefully there's a way to hook up 3 or 4 (possibly more) of these switches, because I know there are people who daisy-chain their gscart and gcomp switches; would probably be a hell of a lot simpler if the EXT header used something like i2c. (Maybe little i2c modules can be built to interface with EXT instead of directly?)

Taking this a step further (and a step further off-topic; I'm sorry, borti), since we're talking about remote-controlling the OSSC with an IR blaster, if you were to use something like a RasPi Zero W instead (something with both GPIO and networking that can run a web server), you could [relatively] easily build a web UI to not only configure your profile-to-input associations, but also build your profiles, and then automatically reconfigure the OSSC. Hell; if you could hook up to the OSSC's JTAG port, you could, theoretically, remotely install firmware updates. And, since it's all remote and automatic, you could hide everything in a cabinet somewhere.

Seems quite easy, current input is just output over three pins. That would be trivial to read out from any device with GPIO, even from multiple switches. Not a project for me, though. I'm rocking passive & manual switches for cost / simplicity / compatibility

Discussions like these always bum me out a bit because the barrier of entry for hacking on the OSSC is so high for me. I know a lot about 8 bit CPUs, DSPs, RPis, embedded, GPUs, 2D/3D graphics programming, web interfaces for home automation etc. Thing is, I don't know a HDL or any FPGA toolchain. Most things with the OSSC involve either the FPGA and the softcore CPU is weak and almost out of program memory.

I'd kill for a video processor that also has a standard SoC with a powerful ARM CPU and a programmable GPU. Having a networked device with a CPU powerful enough for a web interface would be so awesome for managing / editing / sharing profiles or taking & downloading screengrabs, integration with other devices etc. Optionally dumping the output from the FPGA into the FB of a GPU would be so useful. Yes, it would inevitably add a frame of latency but would also solve all display compatibility issues and would allow anybody smart enough to monkey around with shadertoy to develop new processing bits & pieces. Even a cheap, old mobile GPU like the one in the RPi can do a lot in 1-3ms. I have so many fun little ideas like an automatic image glitch fixer that analyses the console's output with known test pattern like from the 240p testsuite and then creates a compacted multidimensional lookup table to counteract image defects like jailbars or the dreaded vertical line. Or you could maybe even have a test pattern that measures 1-CHIP ghosting and tries to fix it in software as much as possible. Or if there was a programmable DSP or powerful enough CPU I'd love to play around with filterbanks and other noise removal techniques and see if I could come up with ways to mitigate the intrinsic PCE whine/hum. Ah well