[14:04:14] NASSP Logging has been started by n7275 [14:04:16] q [14:24:35] good morning [14:25:11] I need to remember to restart more often [14:26:28] good afternoon! [14:31:00] I need to implement too much ugly code for this ARM display, so, I think I first need to do some RTCC cleanup before proceeding [14:42:46] we can run the RTCC MFD in the CSM and LM and a lot of processing uses the vessel you are currently in [14:43:45] Alex implemented a simple MOCR with lots of MFDs, but, not everything works when you are in there because of using current vessel (in that case MCC) state vector and masses [14:44:08] this is now also a problem with the ARM display that I want to avoid [14:44:31] so I will probably implement a CSM and LM vessel pointer you can set in the RTCC MFD [14:44:38] instead of using current vessel [14:44:51] MCC also has these, but, I am not sure I want to use the same ones [15:46:13] does the RTCC class itself have pointers to the vessels? [15:49:02] it doesn't store any, no [15:49:11] MCC has CSM + LM + S-IVB pointers [15:49:32] RTCC has plenty of functions that take a vessel pointer as input to do something, like, get masses [15:49:43] but it doesn't permanently store vessel pointers [15:50:00] RTCC MFD saves the name of the "target" vessel I think [15:50:21] but MFD saving doesn't really work in the External MFD, so, any MFD saving is really being phased out [15:50:32] so I think I would store these new pointers in the RTCC class [15:50:36] and save/load the names [15:51:22] these pointers would correspond to what you would also use on a MPT [15:51:34] so the "LM" can be S-IVB on Apollo 7, Skylab on those missions etc. [15:53:25] So there will definitely be only 2 pointers be stored [15:54:59] MCC pointers aren't VESSEL class but instead Saturn and LEM classes, so it can directly access those [15:55:24] that's one reason why I want to keep these new pointers, I am thinking about, separate [15:57:56] likely you will always keep the same vessels for these pointers throughout a mission, but, I still want that flexibility [15:58:38] this would go on the config page, or maybe the init page where you also select the RTCC files [15:58:54] but first, cleaning up haha [19:24:11] cya! [16:40:05] hello [16:42:24] hey Matt [16:43:33] morning! [16:56:29] hey Mike, nice LMS manual :D [16:56:34] very technical haha [16:56:40] thanks! indeed haha [16:56:43] anything useful in there? [16:59:16] uhh I have mostly looked for malfunctions at first, but, I haven't looked through it all yet [17:04:01] degraded RCS thruster (selectable 0-99%) would be fun. These kind of "analog malfunctions" are not possible yet in NASSP, but, I'd like them to be [17:04:34] right now only malfunctions of the type where it's either failed on or off are supported [19:56:23] night! [12:42:09] good morning [12:47:01] hello hello [12:47:28] what have I started with this RTCC MFD vessel stuff... [12:47:34] not a small project :D [12:54:36] but I'm going through with it. If I talk about any other project tell me off for becoming distracted! [13:12:04] haha, can do [13:12:35] let me know if I can be of any help [13:15:09] thanks! Probably just a bit of testing in the end, but, maybe something else comes up. [15:55:54] morning! [16:03:16] hey Mike [16:16:23] hey [17:17:22] my concept with only 2 vessel pointers almost completely works [17:17:35] it fails in the case of a Saturn IB launch targeting and uplink haha [17:17:57] because with docked stages on the Saturn IB (IU not in Saturn class) you need at least one more pointer :D [17:22:15] is there a future where the Saturn V becomes docked stages as well? [17:44:06] a future, yes haha [17:44:11] we need it to launch Skylab [17:44:25] and finally, properly, get those beautiful animations when it unfolds [18:00:03] oh right! I wasn't thinking about skylab but that makes sense [18:50:21] old vessel pointers all deleted! [18:50:30] wow that was exhausting haha [18:50:49] tomorrow will be a big test day I guess, where I check if anything in the RTCC MFD still works [18:54:11] nice! [18:54:17] that is great progress :D [18:58:51] this wasn't the kind of change I was going to tackle piecemeal, I really just had to work on it for a few hours with full concentration [19:03:05] I'm rapidly converging on 1) not needing to be at work this weekend, *and* 2) it being a rainy weekend so I have no excuse to go out and enjoy the weather, so I might even be around this weekend [19:05:57] ooo, I need to write the spring deployment for those Skylab at some point [19:06:20] or the spring simulation for the depolyment rather [19:09:35] our separate S-II vessel is going to get a whole bunch of code just passing information through from the IU to the S-IC haha [19:10:58] yeah, that definitely needs to happen without a 2 timestep delay, that should be pretty easy though [19:12:07] oh it's going to be instant with the connector class, I was just worried it might require a bunch of code [19:12:23] in a way it's realistic, any separate wire is an interface between stages [19:12:37] main reason why they developed the switch selectors, so they could do more with fewer wires [19:16:43] Maybe we need some kind of class that "bundles" connecters [19:22:02] yeah, I think the S-II just passing through information might be a good test case for something like that [20:39:30] night! [13:26:50] good morning [13:34:18] hey Matt [13:54:08] I've made it to a draft PR with my RTCC MFD rewrite [13:54:35] I bet if I pick a random display of it there is still a high chance of running into issue haha [13:54:40] issues* [13:56:41] I think I am going to start flying a random non-MCC mission to test how the workflow is now [14:43:15] morning! [14:48:10] hey [14:55:30] how's the RTCC going? [14:58:46] just launched Apollo 15 to give it a bit of a test, how everything feels when actually flying a mission with it [14:59:10] so far no new bugs :D [15:02:57] oh wow, nice! [15:03:02] that was fast :D [15:04:13] yeah, I just had to get the majority of it done in one go, otherwise there was a real danger of it not getting completed [15:04:29] mainly due to not having a good feeling about having all the changes under control [16:12:01] digging back into my telemetry branch. it's a bit hard to pick up again [16:44:43] Yeah, when I start a project I am not properly commenting all the code. So often WIP code is really hard to pick up again, if I didn't get far enough to start a bit of cleaning up and such. [14:25:15] hey Nik [14:31:03] hey [14:39:58] some progress with telemetry processing? [14:43:33] this "RTCC as an external application" doesn't want to go out of my head with that (and other) topic haha [15:10:29] a little bit of progress, I figured out where I left off at least [15:12:15] I'm not opposed to the external application idea, but I do wonder how we would do it without making it a necessity to have an external application running [15:13:58] and it would need a lot of information about simulation state (time acceleration, startup and shutdown of orbiter, etc) [15:15:56] on the other hand, IBM 360 emulators keep getting better, and part of me really wants to dream about running some RTCC functionality under OS360 with some realtime task functionality hacked in [15:17:30] Why would the application need to know about time acceleration? [15:17:44] I guess it would need to know about simulation time [15:18:15] I was thinking to make it as barebones as possible in terms of Orbiter API [15:18:21] definitely needs state vectors though [15:19:58] aside from that, TCP/IP telemetry [15:20:13] My thought for an "external" RTCC, was more along the lines of a "RTCC client" that would handle all display drawing, etc, and a terminal for MED imput. [15:22:19] yeah, but also run all the RTCC calculations, too [15:23:55] a completely standalone RTCC, only interacting with Orbiter via a few API calls and the rest TCP/IP [15:24:05] that was my idea at least [15:24:24] You would then be able to use this to run a mission for yourself or for someone else via the Internet [15:25:11] What if we did some kind of Orbiter Plugin, that only served as an interface between the vessels and an external application [15:25:56] yeah, that would need to be part of it [15:26:07] to be able to get the data [15:26:12] The vessels communicate their telemetry, and get their commands from it, and it sends messages with metadata along to the RTCC application [15:26:35] I haven't looked much into how Orb::Connect works, but, it think it is similar [15:26:41] I* [15:30:03] We will at least some communication with the Orbiter API [15:30:14] all of the telemetry stuff is already sent via TCP/IP [15:30:23] you can get REFSMMAT, state vector etc. from that [15:30:29] AGC state vector only of course [15:44:51] well, I'd think we would want to centralize the communication for the vessels. Move the TCP/IP code outside of the vessel code: vessels --internal calls--> plugin --TCP message --> client [15:46:01] that sounds like a large amount of work inside of NASSP [15:46:21] I was hoping for the least invasive approach on Orbiter [15:46:33] so only send out some additional API information like Orb::Connect [15:46:42] and utilize what we already have with TCP/IP [15:47:35] with this approach there is basically zero changes to NASSP code [15:47:45] just an additional (hopefully small) Orbiter plugin [15:47:49] and then the external application [15:50:15] that does sound way easier [15:53:42] at least for the code inside of Orbiter including NASSP [15:53:56] if this is easy for the external RTCC is another story :D [16:00:02] But yeah, this external MFD would have the same RTCC displays (now also in the correct aspect ratio!) as the MFD [16:00:10] external RTCC* [16:00:31] and potentially plotboards [16:01:14] bonus points if you can have multiple people over the Internet play different flight controllers. But, uhh, that sounds very difficult again :D [16:13:00] there are way easier ways to do 2D graphics outside of Orbiter, so plotboards and displays would definitely be doable [16:14:53] if we had multiple people using this external RTCC I'd think we'd still want one single "RTCC server" that everyone connects to, irrespective of whether it was internal or external [16:15:34] maybe I'm overthinking it though [16:19:38] that probably makes sense [16:21:37] time acceleration might be a bit more of a problem than I initially though [16:21:39] thought [16:22:01] There are displays in the RTCC refreshing at a specific rate [16:22:13] are those updating faster if GMT progresses faster? [16:24:23] They do in the RTCC MFD [14:56:53] good morning [15:00:58] hello hello [15:22:39] what's up? [15:23:44] speeding through Apollo 15 [15:24:00] just making sure everything works with my RTCC MFD update [15:24:09] nice [15:24:10] and I will have a nice scenario to test the tweak burn displays afterwards [15:24:17] I see your telemetry draft PR [15:24:47] yeah, I figured I'd put it up there so it was at least visible [15:24:53] doesn't do much yet [15:26:18] I need to decide if I want to really dig into the actual telemetry processor documentation, or just impliment processing the way the telemetry client does [15:27:20] if you figure out how locking onto CMC downlink lists really works, especially the erasable memory dump which is different from normal downlink lists, plays tell me :D [15:27:59] from what I know how it really works this all can at least be implemented systematically step by step, the several layers of processing the data [15:28:44] I guess first comes saving the raw telemetry data in the correct storage locations based on the position in the downlink list [15:28:59] from what I can tell, the dowlinked telemetry words can act as commands to the processor [15:29:53] the way our client works it's essentially just doing: input(word,frame) --> output(address) [15:30:43] oh I see [15:33:00] need to ready more to fully understand, but there are some clues in the systems handbooks that tie in with the processor documentation [15:40:23] I've mostly read about CMC downlink lists in the last few months, I am getting confused, because there is a separate system to locking onto CMC downlink lists [15:44:45] AGC not CMC really haha [15:53:42] the univac telemetry computers also play a big (but unknown to me) role in processing. I believe they share some memory between the MSFTP and the univacs [15:58:56] it seems like the real distinction between the telemetry processors and the telemetry computers is bit-orientedness vs word-orientedness [15:59:23] but the lines are rather blured [16:09:39] seems like the least clear part in all of this is what happens before the RTCC [16:09:52] in the RTCC we have a fairly good idea what is done [16:10:08] down to the program flow of the "unscaling" function [16:11:09] which will have to be the most efficient function we ever write :D [16:54:22] I have another branch somewhere with a Intermediate Data Array implimentation started based on the IBM docs [17:02:31] only 2119 commits behind: https://github.com/n7275/NASSP/tree/RTCC_tlm_arrays [17:05:59] reading through the code, my comcept for this has evolved quite a bit since I wrote most of this [17:22:36] *concept [17:46:47] morning! [19:03:41] hey Mike [19:52:31] what's new? [20:02:15] not a whole lot, mostly thinking about how I want to design this DSKY driver board [15:25:38] morning! [15:51:21] hey guys [16:57:02] hello hello [20:12:10] got a Blender lesson from Jordan. I understood at least 5% of it! [20:13:05] It's one of those things, either I teach him enough about the LM to know where all cue cards have to go. Or I learn Blender and position them myself. [20:13:27] Sort of a paradox of: should expert in A teach B, or expert in B teach A :D [20:13:33] hehehe [20:44:00] night! [14:41:43] hey [15:28:04] hey Nik [15:53:03] Activating the LM on Apollo 15 today [15:53:33] But I think with my RTCC MFD update, I don't need to go through a whole mission, I just need to check a few more MFD pages individually and then I can take the PR out of draft [15:56:28] I will give myself a good scenario to test the tweak burn displays though, so I am definitely going to continue the mission [17:00:18] So your PR makes the MFD completely independant of the vessel you're viewing it from? [17:00:27] exactly [17:00:49] you select CSM and LM on the config page [17:00:58] morning! [17:01:23] also helps reducing confusion sometimes when you have to select MPT or state vector uplink vessels, it now shows the currently, RTCC MFD wide, selected CSM and LM [17:01:30] so you rarely have to change the vessel on those pages [17:01:32] hey Mike [17:01:58] what is not perfectly implemented right now is if each individual calculation page has a way to change CSM and LM [17:02:10] some didn't have extra space for it [17:02:32] but in basically all cases it at least shows you on the screen what vessel it will use for a calculation [17:02:51] In a bunch of cases I have reused the MPT vector time input to show the vessel name, if MPT is inactive [17:17:38] ahh nice. [17:28:03] Not sure if you saw it on Discord, but a fun side effect is that I wasn't in the CSM during launch, instead I went to the MCC vessel, which has a simple MOCR, and watched the two FIDO analog launch displays from there :D [17:38:16] I did see that. Very cool. [17:39:14] Now we just need to get some lua scripts setup to fly the mission for us, so we can spend the whole mission in the MOCR :) [17:39:28] exactly [17:39:51] for on-orbit maneuvers there are also some maneuver monitoring displays [17:40:02] might be fun to watch during e.g. TLI or so [17:40:30] like these launch displays they exist as plotboards but also TV screen versions [19:25:07] how much do we know about the MOCR TV's buffer system. I know some of the early IBM terminals used delay lines as a "frame buffer" [19:52:21] hmm, not enough [19:53:34] I guess the step before that would be knowing more about the Display Formatting Language [19:53:43] we don't have much about that either, right? [19:54:07] NTRS ID 19730062603, PDF pages 297+ talk about that [19:55:30] the information had to be centrally stored of course, because as many people as wanted could watch an active TV channel [20:38:47] night! [16:39:30] morning! [16:49:32] hey [16:53:21] how's the RTCC doing? [16:54:10] hey guys [16:54:54] hey hey [16:55:00] indy91, I went back down the "what do we know about display format language" rabbit hole last night again [16:56:37] sorry for causing that :D [16:57:02] thewonderidiot, just crusing along in Apollo 15, just have to make a small RTCC MFD display tweak here and there [16:59:56] nice :D [17:04:32] I set that PR as ready. I'm sure there are still some details to work out, but in general it is mergable. [18:52:58] indy91, I reviewed that one. I gave the code a good look-over and built it. but I certinaly havn't tested everything [18:54:53] oh great, thanks! [18:55:12] I'll give the changes for the Maneuver PADs in the MCC missions another pass to make sure [18:55:23] But it's changes to ALL missions [18:55:39] so would be excessive to expect testing of all MCC missions :D [18:58:19] full mission anyway [21:28:15] night! [11:43:10] hey [11:45:20] hey Matt [11:45:50] I guess your IMU has gotten a good review haha. Like you asked I will go through the padloads as a sanity check on addresses etc. [11:45:59] IMU PR* [11:57:11] I would say once Ryan finishes his rendezvous, we should be good to merge [12:00:34] awesome [12:04:44] Does that mean I should do the optional P52s in the future? :D [12:16:09] probably haha [12:16:43] although the bias and drift compensation do a good job [12:17:44] I need to work on a writeup for the forum [15:04:18] there is a MED I just discovered, J02. "Specify GET of ascent engine cutoff". I wonder if that would have been used as insertion time for the tweak burn displays. [15:04:33] maybe as backup, automatic being switch setting of the FIDO [15:05:05] but I know basically nothing about the J-letter MEDs, that's where I am very much missing the Volume 3 of the IBM RTCC "General" document [15:05:47] wherever that is. Volume 1 was on NTRS, Volume 2 at UHCL. Volume 3 ??? [15:06:08] 1 at UHCL, 2 on NTRS* [15:13:19] or a later RTCC Operational Support Plan [15:29:27] oh interesting [20:21:42] night! [14:52:50] hey [17:34:24] "the numbers in the value and remarks columns may not exactly match those in the octal column due to use of octal conversion tables. Error is insignificant" [17:34:35] padload creators being lazy :D [18:09:42] n7275, I have started to check the padloads in your PR. Apollo 7-9 for the CMC all check out in the mission scenarios. I am adding the biases to the padload generator as I go along. I'm seeing a difference in the Apollo 9 LGC compared to the flown padload. PBIASY, address 1454, value 1744. Your value is 1454 like the address. [18:16:19] ahh, that would be an error [18:16:23] whoops [18:17:56] also see my quote above, because of their tables the padload generator doesn't agree with the padload document... [18:18:37] I think for later missions they do it more accurately though [18:18:42] so not a problem for all missions [18:31:05] I found another error, I'll write it on Github, easier to keep track of it. [18:48:43] Reviewed it up to (and including) Apollo 10, found a few more errros. [18:58:14] I ran across the discrepancy in early testing, when I was seeing some drift still [19:03:51] with the Apollo 9 padload? Yeah seems like a weird thing to sacrifice precision by just using a table. [19:04:00] it's not like that anymore from 10 on [19:04:08] maybe they got told to calculate it properly :D [19:05:27] well my change requests are on Github, up to Apollo 10. I'll continue with Apollo 11 tomorrow. I bet there are less issues with the padload documents being fully available. [19:05:55] you should of course cross check my change requests haha [19:23:00] In my tweak burn branch I also made some changes to MED processing. Now I want to research IBM 360 macros, because they apparently made use of that for MED decoding... [20:45:21] night! [21:32:18] indy91 https://bitsavers.org/pdf/ibm/360/tss/GC28-2004-6_Time_Sharing_System_Assembler_User_Macro_Instructions_Nov79.pdf [21:32:29] .tell indy91 https://bitsavers.org/pdf/ibm/360/tss/GC28-2004-6_Time_Sharing_System_Assembler_User_Macro_Instructions_Nov79.pdf [15:04:47] good morning [15:06:27] hey Matt [15:06:48] ah, some light reading for the evening :D [15:35:03] haha [16:12:13] n7275, for some reason the LM descent O2 tank has 3800 PSI before being used, with ideal gas I am calculating 2800 PSI with the mass filled at launch. [16:12:34] its energy should be kept at 70°F by cheaty code [16:13:13] DESO2TANK <-1.0 -1.0 1.0> 84.525787 0.0000001 [16:13:14] CHM 0 21772.5 21772.4 4215668.006715239 [16:13:15] in the config [16:13:23] DESO2TANK 84.525787 0 1 0 0 0.00010000 0.00010000 0.00100000 0.00100000 [16:13:24] CHM 0 21638.285135701866 21616.646850566165 4192830.463044715114 [16:13:25] in the scenario [16:39:00] hmm [16:42:07] 3800 is very high [16:43:24] I bet it's the thing that's geting our CSM cryo tanks [16:44:51] there's 21.6 grams "liquid", which has the correct density, but I picked a compressability that was a bit too high [16:47:47] I've been working on some kind of dp/dv = f(p,T) lookup table to tame the effects of the cryo fans, that should help here too [16:55:56] yeah, maybe the bit of liquid is the problem [17:00:22] the main problem with that is that because it's warm it's very "big", and also very incompressable [17:02:43] I'll transition to easier projects for the rest of the day, like checking your PR :D [17:04:36] I'm kind of amazed at how many mistakes I made on Apollo 10 [17:07:07] remember when we had separate MCC and non-MCC launch scenarios? [17:07:18] oh yes [17:07:21] Somehow I introduced differences between them in the padloads over time [17:07:38] which I found when the non-MCC scenarios were deleted :D [17:08:38] I have a vague memory of that [17:44:29] n7275, I've got some more changes for you to do, I am afraid. [17:44:39] comments are on Github. [17:44:47] Apollo 9 is now nearly perfect at least haha [17:45:13] but on 10 you accidentally did a change to the CSM bias when the LM bias needed to be changed [13:48:44] hey Nik [13:50:36] good afternoon! [13:53:12] I think it's time I get new glasses [13:58:18] haha oh no [13:58:54] diagnosed with C vs. L weakness? [14:08:51] lol, aparently [15:47:03] morning! [17:52:59] hey Mike [18:38:18] Ron keeps himself busy judging by the number of commits :D [19:32:19] hahaha yes [19:32:30] he is definitely in a strange mood, to use dwarf fortress terms [19:33:09] Comanche 67, 72, and 72/3 were enough to snap him out of it briefly, but he can't pry himself away from the project for long enough to post documents :P [19:38:38] "I have all the compiler stuff ready, you can give me the Shuttle software now." Maybe it works as an argument [19:39:23] it's certainly worth a shot, in the off chance it actually works [19:41:33] so far he has been pretty good at finding these people and convincing them to preserve the software [20:59:11] night! [17:39:53] morning! [17:52:46] hey guys [17:54:09] indy91, I cannot remember where my values for Apollo 12 came from. I'm going to just re-do those. I thought I had notes somewhere on the data source for everything, but I can't find it. [12:02:40] hey Nik [12:03:57] hey [12:04:22] Maybe you got the Apollo 12 values from the mission report supplement or so? [12:04:54] I can't say I am seeing the same values there though... [12:06:00] at least initially I would like us to match the flown padloads if we can [12:06:32] maybe later we can be so bold to use known differences between IMU bias and compensation in the padloads [12:31:59] I would agree. I'm going to just update them with the padload-matching values [12:33:59] where was it, Apollo 9 LM where the padload document says they used tables instead of doing an exact conversion? [12:34:05] In that case it can stay as you did it [12:34:14] flown padload + the biases given [12:37:50] I've encountered a fun bug in the RTCC coasting integrator [12:37:54] well, as fun as NaN can be [12:38:09] it chooses the step size like the AGC, a function of state vector radius [12:38:18] integration step size [12:38:33] for us that's a minimum of 80 seconds [12:38:38] roughly [12:38:45] but the AGC doesn't take atmosphere into account [12:40:06] our Apollo 11 pre LOI-1 scenario encounters this issue. When it comes back to the Earth atmosphere it still uses 80 seconds steps. Which apparently is enough to cause problems deep in the atmosphere. It encounters a huge drag acceleration and gets slingshotted backwards(!) at 47 km/s [12:40:30] and that causes problem with the conic calculations in the integrator [12:40:32] NaN [14:24:43] 47 km/sec is rather fast [14:25:41] Yeah. Still, I thought the conic routine is a bit more robust, but, apparently not. [14:25:56] The actual fix is of course to reduce the integration step size in the atmosphere. [14:26:17] I might have to study our old favourite MSC document for that, the "verifcation of propagation control package" one [14:27:36] I remember, because of the integration method it uses, it profits from keeping the integration step size constant. So it doesn't change the step size all the time but only upon reaching a certain radius it switches to a different step. [14:31:33] I don't remember exactly how that works, but I'm pretty sure I remember seeing that in the code somewhere [14:34:33] Encke's method also becomes a bit useless in the atmosphere, but, it doesn't really have to integrate all the way to the surface usually [14:35:15] well, it does integrate to 50,000 ft during a trajectory update [14:35:36] this being the coasting integrator it doesn't have to be super precise with that though [14:35:46] just shouldn't make it crash :D [14:46:43] trajectory before LOI-1 is a bit steeper than normal reentry, -7.6° [14:46:48] 2.9 NM vacuum perigee [14:47:33] I guess with 80 seconds integration step size it dips deep into the atmosphere within 1 integration step [14:47:45] and just totally gets confused, I saw 24 Gs acceleration :D [14:48:24] I can throw computer power at this, I might simply let it do 2 seconds integration steps starting below EI altitude [16:50:45] morning! [16:57:08] hey Mike [14:44:48] hey [14:56:57] hey Matt [14:58:41] as typical I ran into some RTCC gremlins [14:58:54] I'll try to get back to checking your PR soon [15:10:23] no rush, I think I still have a lot of things I know I need to fix [15:11:19] for Apollo 12 though. it should just be updating the mission cfg though [18:52:45] watching the football. Cya! [15:25:13] hey [15:56:20] morning! [16:01:10] hey Mike [16:01:29] what's up? [16:02:07] trying to make some progress with these tweak burn displays today [16:02:09] and you? [16:03:04] been super busy lately... haven't had much time to work on anything [16:06:06] making slow progress on getting the DSKY fully powered up though [16:06:20] I have the harness built and schematics mostly drawn, just need to lay out the board [16:07:08] I'm excited to hear (or not) what it actually sounds like when being updated at full speed [16:09:44] haha, I'm sure it will sound nice [16:14:47] some programs nicer than others [16:17:12] *click, click, click* ah yeah, must be P63 [16:24:27] hehehe [14:48:54] morning! [14:56:47] hey [14:57:17] what's up? [14:57:47] ah, I am just eternally unhappy with how I do inputs and outputs with the RTCC :D [14:58:01] hehehe [14:58:14] unhappy enough to try to do something different? [14:59:48] I don't know, I had just implemented something different [15:00:04] my latest version was this: https://i.imgur.com/8w9C4my.png [15:00:11] Automatically generated MED input pages [15:00:38] fairly user friendly with the inputs and then internally the correct processing and error checking logic like the real RTCC can be done [15:01:09] but what's not user friendly is that there is no direct feedback that what you input is now in the right data table [15:02:27] for these displays I let the code load a default input value for each itme [15:02:28] item* [15:02:49] but what is confusing to me now is that you might have entered a non-default value earlier [15:02:55] and internally that value is still stored [15:03:07] but then you go to this page again and it shows the default value [15:03:17]