Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Technology of iCircuit 3D

praeclarum.org

Post reply on HN
Print view View original

11–18 of 18 posts

Re: The Technology of iCircuit 3D

#11

Post by praeclarum »

nbevans wrote: post #4
MattRix wrote: post #3

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.

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

#12

Post by praeclarum »

scrumper wrote: post #10

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.

Re: The Technology of iCircuit 3D

#13

Post by jayd16 »

praeclarum wrote: post #9
jayd16 wrote: post #2

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

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.

Re: The Technology of iCircuit 3D

#14

Post by jayd16 »

pjc50 wrote: post #5
jayd16 wrote: post #2

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...

Re: The Technology of iCircuit 3D

#16

Post by praeclarum »

diimdeep wrote: post #15

@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.

Re: The Technology of iCircuit 3D

#17

Post by scrumper »

praeclarum wrote: post #12
scrumper wrote: post #10

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!

Re: The Technology of iCircuit 3D

#18

Post by MattRix »

nbevans wrote: post #4
MattRix wrote: post #3

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.

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.

Post reply on HN