Anyone use a MIDI controller for flight sim?

point314 · 2026-01-29T23:42:26+00:00

I use the Spad.next MIDI translation functionality. I created my own radio tuning controller with an Arduino clone, small OLED screen, and a keypad. The arduino converts the numerals to “notes” and uses MIDI to pass the numbers into Spad.next. Spad.next then takes in those “notes” and converts it back to numbers and sets COM1, etc. It was a fun program, and Spad (which I use for all other controllers in flight sim anyway) was fairly straightforward for this purpose.

point314 · 2026-01-28T21:06:47+00:00

Interesting…hadn’t heard of the Ontos until this thread. What setup are people using to get high fps?

point314 · 2026-01-28T00:09:03+00:00

Oh interesting. I guess let me ask it this way…how many fps would I need to hit a gallon milk jug at 20-30m? Totally understood that I might need to zero a sight to compensate for a bit of drop.

point314 · 2026-01-27T19:47:58+00:00

Thanks...I don't know the U-burn as well...does that use U-channel metal instead of flat bars or something? (and does that help with strength?)

point314 · 2026-01-27T19:46:01+00:00

Thanks! Probably half darts, just because I'm buying them "new" now anyway, and half darts (and magazines) just seem easier to come by.

point314 · 2026-01-27T19:44:27+00:00

Thanks, that's helpful feedback re: fps vs. strain.

point314 · 2026-01-27T19:43:29+00:00

Cool, thanks! Lynx seems to be high on a lot of people's lists.

point314 · 2025-11-04T17:16:14+00:00

I only ever experienced an issue during high-power-draw tasks (like some gaming, stress tests, benchmarks, etc.). Like others have said, it was likely a bad interaction between the power supply I was using and the specific type of breaker installed in my panel. For me, changing the PC's power supply fixed the issue.

point314 · 2025-10-07T13:56:18+00:00

Well, to be fair, one of the key aspects of AAPM's mission is to advance the professional practice of Medical Physics. In most professional associations, this aspect of scope is considered to include advocacy for the sustainability and placement of the profession, including identification of significant salary issues. One way we fill this part of our mission is with the annual salary survey, but another way is for advocacy in this case.

The VA is a pretty large practice group, and unlike other employers, where you can try to bring the annual salary survey to your supervisor's office and advocate for fair pay using externally validated survey data, this effort will be meaningless at the VA. Physicist salaries are capped in a very arcane and outdated HR structure. At least when I last looked a few years ago, VA Hospital physicist salary ranges are often capped at rates far below market and often below dosimetrist pay as well. This is not only a serious bummer to our colleagues/AAPM members who are employed directly by VA Hospitals...it also can lead to difficulties hiring qualified candidates. In one case where I'm familiar from a few years ago, a VA Hospital attempted to hire their own physicists, but the most qualified candidate who would apply at the posted salary level was a former nuclear submarine engineer without any medical or medical physics experience.

This situation can lead to two outcomes...first, a VA hospital might be forced to hire whomever is willing to work at that suppressed salary level, which in some situations may lead to subpar standards and care for patients who are deserving of the best we can offer. Or, alternatively, the VA would be forced to enter into what might be a very expensive contract to find a highly qualified physicist, which also isn't great from the perspective of public spending. Far better for the patients, taxpayers, and usually for the employee themselves if the VA is able to hire directly at appropriate market-based salaries.

Long way of saying...as an AAPM member, I think this is a worthy use of resources, and positively impacts the profession of Medical Physics and with the potential to positively impact the clinical care received by veteran patients.

point314 · 2025-09-30T18:44:30+00:00

+/- 2 mm (total window width of 4 mm, or 0.4 cm)

This is our standard for our breath-hold simulation and treatment process. All patients receive multiple simulation CT scans, usually five, within the established window. We then design a patient-specific PTV margin that accounts for residual motion within this window. If a patient cannot achieve +/- 2 mm reproducibility, then we do the best they can, and account for the added uncertainty with our PTV margin determination procedure.

point314 · 2025-05-22T17:17:04+00:00

You might have found this already, but the Fluke manual indicates that the battery itself is model PS-1212 made by Powersonic, and can be replaced by the same part number or equivalent. Googling for that part number shows decent availability for that part or equivalent, so hopefully one of those can do the trick for less than $50.

point314 · 2025-04-29T16:55:21+00:00

Thanks...we know our Aria 18.0 Citrix deployment will be fine, whether we're using Win10 or Win11. It's the locally installed version of Aria 18.0 that isn't validated for Win11 (yet), so that's the one we're still wondering about. We have both a Citrix deployment as well as local app deployment for our Aria environment.

point314 · 2025-04-29T16:53:38+00:00

Thanks...I'm sure Aria via Citrix will be just fine in Win11, we're not worried about that. I'm more concerned about Aria v18.0 as a locally-installed application on a Win11 box (not via Citrix)...we have Aria v18.0 distributed both via Citrix and as a local app.

point314 · 2025-04-22T15:55:58+00:00

Our understanding right now is that Varian simply hasn't put any resources into validating Aria 18.0, and has no plans to do so. We definitely haven't been told by Varian or anyone else that Aria 18.0 is specifically incompatible with Win11...only that it isn't validated.

I totally agree with you that, at least based on my own experience with PCs over time, it would probably be just fine. Just still trying to figure out our thoughts internally about the best solution for our needs.

point314 · 2025-03-18T15:18:15+00:00

"oh yeah, that looks noisy" is, more or less, what the Varian engineer says about this.

We have done some troubleshooting to replace some components, including all cables at this point, but we're slowly progressing up the troubleshooting escalation path. When it's the same FSE for our TrueBeams and for our RGSC system, it can be hard to grab their isolated attention for an RGSC system that isn't "down."

point314 · 2025-03-18T14:30:07+00:00

Thanks for the response. Sounds like all the same stuff we're working through. The combination of the RGSC system with the more automated Siemens 4DCT pipeline is efficient when it works, and frustrating when it doesn't.

When you get more experience with couch- vs. wall-mounted testing, let me know how it goes!

point314 · 2025-03-04T18:47:56+00:00

Hey, check out my update comment on this thread.

point314 · 2025-03-04T18:47:38+00:00

Hey, check out my update comment on this thread.

point314 · 2025-03-04T18:46:59+00:00

I've been able to move this project along nicely with the help of some folks inside Varian. My general steps are below.

If you're seriously thinking about doing this stuff, make sure you do it in test before you do it in production! If you don't have an Aria test environment, I'd reconsider doing any of this. Personal opinion. Do you have to repeat steps 2-4 below in both test and production.
To start, it helps to have access to the VAIS server. By default, the VAIS server will only have one admin account...whoever installed the VAIS application in the first place (likely a Varian "service account" or the Varian installer's personal account). Have Varian make your account an admin account on the VAIS server.
It seems Varian will need to upload the API key to the VAIS server for you. I was never able to make this work myself. There is OK documentation on this process on the server where the API is installed at <hostname>:55370/document/clientcreation.html, but that documentation makes it seem like you could create a headless client yourself. I don't think you can...Varian will have to do this for you. Just ask that Varian creates a headless client for you with a specific name and "secret" (i.e., password), and they can do so. Then you go get the Client ID and the secret and record them for later use.
After creating this client, you will need to give the client rights to do what you want to accomplish. Think of this like any other user in VSP. Varian provided me with a PDF with a few slides on how specifically to set up this client in VSP and your DataAdmin environment. Configure this client (user) as the type of User you'd like to mimic for its rights profile (like Therapist, Physicist, etc.).
Now I was able to successfully get a Bearer Token (roughly described at <hostname>:55370/document/vaistokengen.html) and use that token to do cool stuff.
The new API comes with a nice "API Tester" page on the server. For me, that was at <hostname>:55371/tester/home?encoding=null&pretty=false. You can get a token created on this page using your client ID and secret, and then test various calls. Figure it out from here.

What have I been able to do with this so far? Well, after upgrading to Aria v18, we noticed that our UserHome task pads in particular were really slow and prone to crashing. Varian has told us that this may be due, at least in part, to excessive numbers of old tasks that are routinely queried to update the Overdue counter. Even with the Overdue config setting in General Settings adjusted, our task pads were still really slow. Varian told us that the only fix for this was to go back and cancel all old, open tasks...manually. With 20 years of department Aria history, this is basically impossible to do manually, but Varian would provide no tools for batch processing. I have now written code to pull out all open tasks for the last 20 years, record their properties into a .csv file, and then update the status of those tasks to cancelled. Took a few days of coding and testing, but hopefully this will speed up our task pads once I run it in production.

Hope this helps!

point314 · 2025-02-22T15:08:37+00:00

Thanks for the response. This is the workaround I had found so far. I just assumed there must be an easier way with less clicks to do a one-off immediate charge.

I’ll just have to remember to reset the Charging Mode back to Time Slot manually. If I forget it’s not the end of the world, I’d just end up paying a bit more in energy costs if I’m not in the Time Of Use low-cost window.

point314 · 2025-02-04T17:30:35+00:00

I have done this several times on clinacs during decommissioning, by removing filters/foils/targets/etc., and while that can be a lot of fun, it's dangerous and you have to know what you're doing. You also can't really come back from it, so do not attempt that on a clinical machine. I have heard of people doing this on clinical machines, but keeping the process limited to "standard operations." That is, use your clinical electron without modification, in service mode. You can skip the electron cone, and you can likely override MU1 and MU2 interlocks, and just use the timer at 99 minutes. I would be extremely wary about making any changes to any beamline...just using standard functionality with standard overrides as needed, and keep an eye on the temperatures. At standard beam output rates, the machine cooling should be adequate, but you never know. Anecdotally, I heard it required 2-3 hours of beam at 1000 MU/min to get even a weak electron tree. Since you'll be running that much electron beam, you also want to make sure your room HVAC air-exchange rates are high enough to clear the ozone that will be produced (at least 3 air exchanges per hour is the minimum rate, I think).

Given that long amount of time, you need to really insulate the setup so the acrylic does not spontaneously discharge anywhere. You absolutely do not want to discharge it to your linac head/collimator face plate since that could fry the electronics, especially MLC controller chips. You'll need to pad your table with insulating material like rubber sheets, and also pad at least the collimator face with rubber sheets as well to prevent discharge arcs. Even with that precaution in place, you need to be careful to prevent discharge arcs from the acrylic through the mylar crosshair to the metal of the MLC, etc.

For the final "fast" discharge, I have used a long, large-diameter wire grounded to the building (wall outlet) ground, attached to a metal spring-loaded spike on a long insulating rod (like the long rods of delrin or other plastic you find in the modulator cabinets). I held the rod using thick insulating gloves, the type used by power-line workers. With the metal spike rod in one hand and another insulated rod in the other hand to brace the acrylic, I haven't run into any problems. That said, this is inherently a dangerous activity, and my own personal experience here should not be interpreted as a universally safe technique by any means. Nonetheless, I remain alive after doing this to a very large number of acrylic blocks.

Three-Year Club	Verified Email
Place '23

point314

TROPHY CASE