The Technology of iCircuit 3D | Hacker News Reader

The Technology of iCircuit 3D

praeclarum.org

70 pointsdeddo16 comments

Most impressive! I have used iCircuit 2D before and loved it, and looking forward to upgrade.

Very cool, but seems like a bizarre choice to use C# and then lock in to Apple’s stuff. If you’re making a 3D app with C# you might as well use Unity. Something like this could even find an audience on Steam.

He used what he is productive in though and there is nothing wrong with that. Obj-C and (to a lesser extent) Swift are pretty alien to a long-time .NET developer. The author of this app is very active in the Xamarin space and recently contributed enhancements for Catalyst support.

I’m a little surprised he went with SceneKit for rendering. I don’t expect it to go away anytime soon, but it also hasn’t received a lot of love from Apple in the past several years.

Edit: of course it can be great to use what you are comfortable with. Done (and really, really good, is better than perfect.

The way he is using property definitions with SetUndoableProperty seems like a really good fit for Swift’s property wrappers. Instead of writing getter and setters for every property you could just write them in once in the property wrapper definition and then annotate each property with @Undoable.

Nailed it. I started iOS development using Obj-C++ but switched to C# after a couple years because of my familiarity and comfort in that ecosystem. At this point I've used it for 10 years on several iOS and Mac apps and know its ins and outs. I've been accused of making my own job harder but honestly it feels the opposite for me. The .NET debugger, reflection, choice of languages, package ecosystem, it's all very lovely.

There’s obviously something wrong with that, because now he is unable to release his app on other platforms where it would probably find a larger audience.

To be clear, C# is a great language for this project. It’s the choice of using a platform specific library (SceneKit) that baffles me.

Can't wait to buy the original iCircuit, just need it to support vacuum tubes... Any plans to do that or are you really focusing on the Arduino/digital hobby?

This might have use for layout prototyping, thinking about it. But until it has tubes I don't need it.

Nice work - really does look good.

I owe the iCircuit community vacuum tubes. I've been promising them for some 10 years now.

My hesitance has mostly been my inability to verify the simulations. I prefer to have physical elements available so I can double-check the app. But I think I will have to resign myself to verifying against SPICE or something.

Glad to be part of that annoying sense of guilt at the back of your mind :)

For me it's less about modeling the tube and more about checking the rest of the circuit around the tube if that makes sense. Does the tone control do what I want, and so on.

Personally I'm looking to verify relatively simple parameters of a tube in a circuit: gain, whether it's operating in the linear region given a particular bias, that sort of thing. If the model was simply a representation of the tube's characteristic curves that'd be good enough for my purposes.

So being SPICE-like would work ok. After all that's what I'm doing now!

@praeclarum What do you know that no one else that let you bet so much on C#, .NET stack for developing with it for macOS, iOS ? That to me seems really risky.

It’s open source and I have successfully compiled and ran it on my own machine. So I do not fear it going away. The biggest risk is it could not be updated at some point. But, again, OSS. The community could continue the work.

Kind of neat. Why not async and TPL instead of all the manual locking?

TPL?

It seems to be a "classical" OO model with mutation-from-anywhere. Effectively a database in memory.

Excuse me for my terseness, Task Parallel Library.

https://en.wikipedia.org/wiki/Parallel_Extensions#Task_Paral...

There is tons of TPL (Task Parallel Library, async and await), I was just trying to keep the blog simple. Once you have thread-safe primitives, you can build higher level abstractions on top of those. In fact I worked a bit on the TPL when I worked at Microsoft so I definitely abuse it. :-)

Ah ok. That makes much more sense. From the wording in the blog I got the impression it was being avoided with manual locking.

Reply on news.ycombinator.com