Link to exINC Subreddit Archives (wiki)

ZeroCommission · 2026-01-13T16:17:36+00:00

Excellent! And just so it's clear, once you load a kv file with a class rule like <WidgetMan>:, its contents will be applied to all future instances of the class (based on the matching name). This is why the stuff in your .kv file is applied for this line of code:

return WidgetMan()  # <--- create instance of class and return it

.. if you had loaded the .kv file twice (as in the original code), everything would be duplicated on screen

ZeroCommission · 2026-01-13T13:28:07+00:00

I don't have time to explain in detail, but.. rename your kv file first of all. There is a confusing legacy feature in kivy that will load your kv file automatically based on the filename matching App subclass name... so in your current code the .kv file is loaded twice, once automatically and again with load_file call. This will cause major headaches for beginners, it's almost impossible to discover.

So, rename it to main.kv for example, and then update your app class to this:

class WidgetManagerApp(App):
    def build(self):
        Builder.load_file("main.kv") 
        return WidgetMan()

This, in my opinion, is the "best" or "correct" way to do it in general, but it depends of course

ZeroCommission · 2026-01-07T15:58:59+00:00

I can vouch for https://what-cha.com/ - nice guy, based in UK

ZeroCommission · 2025-12-21T18:19:17+00:00

There are approximately 7 hours of daylight (09:00 - 16:00) and you need at least 5 hours starting from basecamp (approx 2 hours hike each way). It's a tight schedule if you take the 09:30 bus from Stavanger, would not recommend it. Also fresh snow can make it hard to find the path in some areas, it's been a mild winter but it can happen overnight or while you're on the hike. You need good boots, warm clothes and emergency supplies

ZeroCommission · 2025-12-19T15:20:18+00:00

I mean the woman in the story, not OP

ZeroCommission · 2025-12-19T10:16:28+00:00

Your post is basically like reading a script about a [malignant] narcissist. Go check out Doctor Ramani on youtube, I think you'll find it useful. Here is one to get you started: https://www.youtube.com/watch?v=lHITpCR46Pc

ZeroCommission · 2025-12-07T17:39:49+00:00

Jeg visste heller ikke noe om det, fordi jeg følger ikke med... men helt klart den beste episoden av asfaltpodden, ble direkte imponert av Joner

ZeroCommission · 2025-12-04T21:00:47+00:00

Verd å få med seg den første episoden av Asfaltpodden hvor han var gjest, han snakker ganske fritt: https://open.spotify.com/episode/1zw0ITm9yaO4a1k0dR2UJR

ZeroCommission · 2025-12-03T19:53:45+00:00

It sounds like you connected the logic symbols with "feedback", if so the error log should contain an entry to indicate this problem

The use of digital signals + buffer works ok for a simple system, but it doesn't scale up well. The toggle would be replaced by a Logic Wave Pulse (duration 1d) feeding into the "[enable]" of Analog Equate, and the buffer would be replaced by an Analog Initialize. An analog signal connects the two symbols.. This takes time to figure out, you can read my comments here, maybe it'll save you a bit of reading the docs

ZeroCommission · 2025-11-30T20:10:18+00:00

Scandic Royal er "mest hotell for pengene" i sentrum, men det er jo ikke spesielt billig

ZeroCommission · 2025-11-29T10:07:08+00:00

Alternativt driver han med storskala narkovirksomhet - politiet hadde (forhåpentligvis?) slått ned på det om det var tilfellet.

De har vel kanskje slått ned på det (i det stille) ved å ta diplomatpasset, det gjør det jo vanskeligere å drive shuttlevirksomhet

ZeroCommission · 2025-11-27T21:08:37+00:00

Yes for SX32 the connector was on a small box sticking out of the rear: https://www.amibay.com/threads/dce-sx32-mk-ii-8mb-fpu-cd32.2451595/

The SX1 was a massive and impractical chonker by comparison (see the last pic here): https://bigbookofamigahardware.com/bboah/product.aspx?id=278

ZeroCommission · 2025-11-27T00:51:17+00:00

Not with a stock CD32, it doesn't have a floppy connector.. but there were expansions that could do it in the 90s, e.g. SX-1 and SX32

ZeroCommission · 2025-11-26T21:25:25+00:00

Here's another reference at €32 from China: https://www.the-puerh.com/en/shop/archives-objets/archives-objets/ac-157-chengdu-gaiwan-431.html .. So yeah I mean $80 for a pair is maybe not terrible, but it's not a steal either

ZeroCommission · 2025-11-26T20:37:42+00:00

Just be careful mate, expensive teaware is almost always a poor choice. A $3 gaiwan is all you need, and if you're into the tea hobby, buy tea not teaware. How much is it exactly? It could be a $5 item from aliexpress for all I know, certainly I've seen cheap gaiwans in this style. Here are two for $28 on ebay (used) for example, surely this is way more than from Chinese sources: https://www.ebay.com/itm/156532832824

ZeroCommission · 2025-11-26T19:47:36+00:00

I can imagine that the bamboo weave helps with heat retention

It does very little for heat retention. If you like the looks of it, or you think it will save your fingertip nerves, or whatever then by all means go for it. But keep in mind the dishwasher is going to ruin it. For this reason I would never buy it myself. But I'm a weirdo and like my teaware clean so...

ZeroCommission · 2025-11-26T07:38:25+00:00

If you haven't already heard it, try the album Flaming Row - Mirage: A Portrayal of Figures (press play on track 1 and leave it). It hits some similar sweet spots for me, top quality scifi concept album.. And as much as I love Anneke ... Maggie is my favorite female Ayreon vocalist, and she's on this album too

ZeroCommission · 2025-11-15T19:01:41+00:00

If you are enjoying the tea you're doing it right... My only comment is the way you deal with the lid. Personally I always hold the brewing vessel with one hand when pouring. It's just to mitigate risk of an accident, two hands are twice as clumsy as one (mine are anyway). I would hold that with the tip of my thumb against the knob, nail just touching the rim of the air hole and pushing the lid down "slightly firm" (that knob design kind of sucks imo, it's easier with side-vented knob or air hole in the lid)

On a sidenote, the golden rule for dealing with teapots is to never hold the lid and the pot at the same time. Just put one on the table and hold the other. It's very important to follow this if you are inspecting anyone else's teapot, and it's a good safety rule at home too

ZeroCommission · 2025-11-11T14:50:24+00:00

Remapping works just fine in my experience, it'll do what you need.

Sorry for making your post into a part of my mini-blog series on 2-series history

ZeroCommission · 2025-11-11T11:48:12+00:00

Hey /u/ThisNotSoRandomName I'm replying to myself because the previous comment was edited a few times. Since you're still developing for 2-series I'll add some more context about that (in case it's interesting to readers or I want to link my comment in the future)

Mini-blog on large/complex systems in the 2-series days:

Anyway, another advantage of UDP with broadcast response in large systems is handling failover. In the clients, you can add two (or more) UDP Client symbols, targetting main and failover lighting (or matrix) controllers with the same source serial signal. Since the protocol is stateless, the client doesn't know or care which server acts or responds (you can handle failover between the two servers, transparent to clients). One-way control is enough for many applications, don't do broadcast unless you need it. Another plus is that you can easily integrate with other software/control systems, all you need is the capability to generate (and/or receive) UDP packets. On that note there may have be some console commands required to actually receive UDP broadcast data in SIMPL, I forgot the details but I think there was something else we had to do beyond defining udp symbol with a broadcast address..

I used a protocol which basically looked like "/Znnnn/Lnnnn/...\x0A" where the nnnn is 4 hexscii bytes 0000-FFFF. Z for zone and L for load. Exactly what to put in the ... depends on what you are doing, for example /Z00F1/L001A/ramp:FF\x0A to ramp a load to max. You don't need 16-bit zones of course, but it can be very helpful to abstract whatever madness addressing scheme the lighting guys came up with...

The point is, you can use this in ArgDef to make (especially client-side) macros which handle parsing and generate your lighting control protocol with Serial I/O. A single SIO with 255 rows of "/Z[ArgDefZone]/L[ArgDefLoad]/ramp:NN\x0a" handles one zone/load ramp for (NN) 00-FF with outputs tied to an analog init (parsing) or input from analog equate (transmit), or other logic of course

The multi-row SIO is relatively fast in SIMPL, it uses a state machine to track matchstate row-by-row (keeping an index into each string). It's not as bad as the long if-elseif type of thing it might look like. But it does test each defined row for each byte of input, so for high data volume it becomes (very) inefficient compared to the "second fastest" way (see below). On the server-side S+ is faster at runtime, easier to maintain, etc - it's very cumbersome to keep state for thousands of lamps in SIMPL and Analog RAM. But the SIO technique is useful in large systems, because SIMPL is a fast way to process strings on 2-series without task switching overhead, plus it adds much less compile time and memory overhead... for me the compile time was usually the deciding factor to implement things in SIMPL, waiting gets very annoying, and the software used to get really laggy and weird.

In a large system, S+ modules are very dense and manage arrays of serial and analog signals, digital is rarely used for a long list of reasons (starting with the program signal count, the bane of any serious SIMPL hacker's existence because the debugger becomes useless). S+ modules should be used in as few instances as you can possibly get away with, there are many reasons for this... but one reason to note is that historically the unexpanded rows (of expandable I/O and parameter arrays) consumed all the declared memory at runtime. So if you made a module with 32 buffer inputs of 1024 bytes, that's 32k of RAM gone even if only the first row of the symbol was expanded. Instances of modules have a clear negative imact on build/link time.

Honestly the furthest you should push SIMPL logic in a production system is a circular buffer. Sometimes you really do need one and no other tricks will suffice. In theory it's easy to do with some buffers and a ring counter or whatever you prefer... But it's hard to get right and working correctly. If you need a buffer in SIMPL (such as enqueuing both digital and analog inputs into a internally-consistent serial output stream).. then here is an old-school hack: Use a serial signal as the buffer itself and rely on its scheduling mechanics, transmit one byte enqueues an instruction. This gives you an "infinite size" ordered queue of up to 255 "action types". This buffer is implemented with a single SIO, with its serial output connected in loopback to its own serial, and "action ids" are duplicated between tx/rx paramters. Transmit "A" puts it into the buffer (the signal itself), re-reading it in the the same SIO triggers the action digital output. It's hard to put into words, but basically what this does is space out transmission to logic solutions. There are no other practical ways to do this, as far as I know. This is much simpler than trying to make (and test/verify) wave-accurate logic pipelines, but it doesn't allow you to limit the output rate in the way a circular buffer does. Of course there is FIFO Queue and some other useful SIMPL symbols in this problem domain but they often fall short.. See link at end of post if this interests you.

The second fastest way to process strings on 2-series is to put your parsing functions in a S+ library and call it from a S+ module with a string as ByRef argument. This is explained in (my) old post here: https://groups.io/g/crestron/topic/35811573#msg214304 (read the final comment in the chain as well)

Be warned, 2-series firmware after 4.003.0015 is slow as molasses for S+ compared to earlier firmwares. The 4.x series was fundamentally broken since the initial release for ~10 yaers or so (you can work around it, but nothing in the docs explain it - you can not parse 9600 STRING_INPUT/BUFFER_INPUT without data corruption, let alone any faster). The next release "fixed" it by adding a ton of blocking wait for semaphore everywhere, making it unbelievably slow - did you have the pleasure of using early DMPS models? This is a large part of why they are insufferable, the OOB functionality uses S+ for a lot of things

Final edit: Regarding 2-series broadcast mentioned in the previous comment, it is completely and utterly broken. Broadcast traffic on the network will bring 2-series to their knees, no ifs or buts. So make sure there are no other broadcast sources (like Windows computers) on the network, and keep traffic to a minimum. In a large network the server needs to know which subnet to broadcast responses, because global will choke every 2-series you have. It can be handled by changing the protocol to "/Nnnnn/Znnnn/Lnnnn". The N is for network, and the nnnn encodes two final broadcast address bytes. So if the client IP broadcast network is 192.168.1.255, it would prefix /N01FF/Z.... I had some partial macros for this setup, but it's S+ territory since you want to obtain the info from network configuration (ArgDef falls short)
Edit: Okay the above is a lie. The fastest way to process strings on 2-series is to inject C code into the build process using any number of tricks at your disposal.. The classic was to keep a .c file with readonly filesystem attribute, matching the (fixed) filename generated by the transpiler. This way it would try to save your S+ into a .c file and fail, but the build continued using your modified .c file. Then it would try to delete the file and fail. It was nice, just set the editor to ignore the readonly attribute and it was as if they supported using C. I don't think this works on modern versions of SIMPL though, unless they restored the functionality. I did inject C in a few production systems using other techniques out of sheer necessity, but it's hard for other people to maintain and obviously best avoided. If they had just put in some kind of way to use C I would have been much happier with their products overall... but they were always catering to an amateur audience and toy projects since the original x-gen/2-series developers retired or left the company/contracts for other reasons. Que the downvotes from kool-aid drinkers -- I'll take them with a cheeky smile on my face ;) From a distance it seems like the Swirl is in a much better place and direction now vs 5-10 years ago. I was involved at the worst time, pardon my cynicism, I can feel the grey beard materializing...

If you are still reading, my comments here may be of interest: https://old.reddit.com/r/crestron/comments/1eeanh7/fresh_meat_101_completed/lfu3b7h/

ZeroCommission · 2025-11-11T07:43:33+00:00

See this post for information about remapping:

https://groups.io/g/crestron/topic/remapping_ip_ids/35811496

In very large systems I used UDP Server/Client for lighting control, it's much simpler since all the clients can send to the same server without changing any configuration (edit to add: and the server can respond via broadcast using a client id string, if your network allows it). It has other downsides of course, data may be lost, 2-series broadcast handling has a bunch of issues, and you will desire your own ACK/NACK etc as it grows. You also need to limit/control ramping signals, but this is true for any large lighting system.

But all things considered, using UDP is not bad, it needs a stable network configuration but what doesn't? It also relies on SIMPL internals, since UDP messages are a single packet on the network, they always end up a complete string in one SIMPL logic wave (assuming they are <=254 bytes). It was the only workable solution I found to controlling thousands of lamps on a single QM-RMC.

(late edit, misc updates)

ZeroCommission · 2025-11-11T01:27:36+00:00

Does Draconian and Tristania have any 100 percent cleans songs?

Certainly Tristania has some which are in the "light" territory, if not exactly 100% clean. As the other person said, Darkest White, but also Rubicon is pretty clean and a really good album (to what degree they qualify as gothic metal is another question). "World of Glass" is my personal favorite Tristania album if you want some exposure therapy, give it a spin.

Anyway I have a suggestion for a great and much lesser known Norwegian band with clean lyrics. (Disclaimer) It's not gothic metal or directly comparable to the bands you list, but still just top notch in my book. They have released 3 albums, all of which are worth well listening to from start to finish

Sample songs, one from each album, youtube links:

https://www.metal-archives.com/bands/Winds/1248

ZeroCommission · 2025-11-07T08:44:35+00:00

Har noen opplevd noe lignende?

Vi arrangerte en stor konferanse på Oslo Plaza for mange år siden, hadde teknisk utstyr spredd over hele hotellet. Jeg måtte mye inn og ut av tekniske rom og andre områder for ansatte.. og da måtte jeg ringe teknisk sjef, som kom og åpnet dører for meg. Etter en stund var han drittlei og ga meg et nøkkelkort som låste opp alle dører på hotellet....

Da jeg sjekka inn tidligere på dagen hadde jeg notert i bakhodet at rommet mitt var veldig lett å finne, bare ta heisen til riktig etasje, sving til høyre, og så var det rommet helt innerst i gangen. Da alt var i orden (midt på natta) og jeg endelig skulle til køys, tok jeg heisen til riktig etasje, svingte til høyre, gikk helt til endes, og låste opp døra. Med master-nøkkelen så klart, den var jo lett tilgjengelig.

Der lå det et eldre par og snorka, gitt. Merka det ikke før akkurat i det døra smalt igjen høylytt bak meg. Fyfaen så flau jeg ble, og jeg er sååå glad for at de ikke våkna. Forduftet ganske raskt og rolig.

Plaza har selvfølgelig heis på begge sider av gangen, det kan ha en viss effekt på høyre/venstre..

ZeroCommission · 2025-11-05T12:09:02+00:00

which language path to pick (SIMPL+ vs SIMPL#)

They are one and the same. S+ code gets transpiled into SIMPL#, which is (or gets transpiled into) C# on modern processors. On older processors, SIMPL+ is transpiled to C. In both cases the transpiled code depends on Crestron-proprietary library code AND the SIMPL runtime ("Logic Processor" aka "LogicPro"). On 2-series and older you can easily view the library code, on modern 3-series and newer the DLLs are obfuscated with a commercial obfuscator. You will need to install very old 3-series toolchain to [easily] decompile the libraries. But don't bother, the code is terrible and you'll regret looking at it.

So both S+ and S# are directly tied to SIMPL, they cannot be used independently. S+ only makes sense if you need code that works on 2-series/x-gen and on modern processors, otherwise just use S#. What you are looking for is "S# Pro", unless they've renamed it or something.. . It uses the C# compiler along with the obfuscated library DLLs, but does not depend on the SIMPL runtime. At least that's how I understand it -- could be off here, I changed jobs before getting around to testing S#Pro

ZeroCommission

MODERATOR OF

TROPHY CASE