Re:The Technology of iCircuit 3D
by MattRix on Wednesday February 10, 2021 @11:20PM
(#26098220)
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.
Re:The Technology of iCircuit 3D
by nbevans on Thursday February 11, 2021 @04:47AM
(#26099821)
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.
Re:The Technology of iCircuit 3D
by praeclarum on Thursday February 11, 2021 @10:29AM
(#26102500)
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.
Re:The Technology of iCircuit 3D
by Pulcinella on Thursday February 11, 2021 @10:09AM
(#26102208)
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.
Re:The Technology of iCircuit 3D
by MattRix on Saturday February 13, 2021 @09:53AM
(#26123882)
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.
Re:The Technology of iCircuit 3D
by scrumper on Thursday February 11, 2021 @10:29AM
(#26102497)
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.
Re:The Technology of iCircuit 3D
by praeclarum on Thursday February 11, 2021 @10:31AM
(#26102535)
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.
Re:The Technology of iCircuit 3D
by scrumper on Friday February 12, 2021 @12:07PM
(#26115830)
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!
Re:The Technology of iCircuit 3D
by diimdeep on Thursday February 11, 2021 @04:02PM
(#26107111)
@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.
Re:The Technology of iCircuit 3D
by praeclarum on Thursday February 11, 2021 @07:07PM
(#26109281)
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.
Re:The Technology of iCircuit 3D
by praeclarum on Thursday February 11, 2021 @10:22AM
(#26102381)
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. :-)
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.
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.
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.
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.
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!
It seems to be a "classical" OO model with mutation-from-anywhere. Effectively a database in memory.
https://en.wikipedia.org/wiki/Parallel_Extensions#Task_Paral...