Sorry to resurrect this old thread but I am stuck getting multiple TCP clients to connect to one server - seems I could use that sample! onAccept in the server only gets called for the first client. Details over on the new forum here. Cheers.
I didn't write those classes, Hai did, but I believe he was running with the design used for ContextWasapi, where you can see how I was able to push a bunch of heavy windows headers to the cpp by using a pimpl. There are cases where you would #include a platform-specific Context implementation header, for example on Mac when you are using audio unit functionality, so it's nice that those headers are lean. In general for platform specific implementation code, I like this pattern.
I am having the hardest time getting parameter events from the audio unit working. I can call "AudioUnitGetParameter" just fine so I know its initializing and getting the parameter when I call it. But when I try to use an event listener...
int id = event->mArgument.mParameter.mParameterID;
cout<<"ID!!! "<< id <<endl;
cout<<"Value!!! "<< parameterValue <<endl;
cout<<"hostTime!!! "<< hostTime <<endl;
cout<<"event!!! "<< event->mEventType <<endl;
// parameters[id] = parameterValue;
I'm not getting any notifications to my listeners but I'm not getting any OSStatus errors when I build my listeners either. If I try property events instead of parameters, I get a few property events at launch but not afterwards. This makes me think that it has something to do with the CFRunloop? I tried following the advice from this thread but no luck and I have no idea what that is doing exactly either. Can anybody get this working?
Sure, that makes sense. We'll just have to figure out the pros and cons of allowing that design. I was honestly never convinced that the error handling in the block was perfect. So, this should allow us to better hone the design.
Do you have an alternative recommendation? We need to move to something else and so far Discourse is the best option for the cinder community, but of course we haven't actually made the move so should consider other choices out there too.
I know Vanilla has been mentioned but I believe it takes much more manual effort to get up and going, along with integrating plug-ins, not to mention hosting.
I know I've been quiet for a while, but when I finished refactoring my code, nothing worked. Took me some time to get back into 3d space calculations 'n such, as well as track down column/row major bugs.
I'm glad to announce that my pose estimator now seems to be solid and back on track. I still got a bunch of clean up to do now as well as some more testing, but hopefully I can have a usable version up and ready within' a few weeks time.
@pjhcinder - Thanks for the kind words. Currently it's looking like one of the next two release cycles. We're working through the details.
@Bala - You're welcome. Haven't decided on a Capture implementation yet....was leaning towards V4L/V4L2. Thanks to @petroskataras, GStreamer is working in Cinder. Suppose we could make a swappable back end for capture on Linux. If you'd like to Pull Request some V4L/V4L2 that would be awesome.
If you're experimenting with the Vulkan branch and are using Visual
Studio 2015 and are running into error C2397 - narrowing conversion
error due to int32_t -> uint32_t implicit casting -.here's
An issue was posted to GitHub that is very similar Problems with build of Vulkan version
which details build problems due to missing boost and vulkan -
sounds as though the initial clone or checkout was not done properly.
Thanks Paul, the exclusion strategy you've described is very handy —
that's how I skippedd third-party code in the forked repo.
Richard, in a typical invocation, ClangFormat climbs directories
from the source file it's called on until it finds a .clang_format
file to use. So I think putting it in the root would only make
intuitive sense if we actually ran the entire code base through the
formatter. Since that's out, I think dropping it in /tools with
some explanatory documentation makes the most sense.
Also just for posterity, you can explicitly exclude code from
clang-formatting at the line level by wrapping it inside // clang-format off
and // clang-format
on comments. (Though obviously this is not a tractable fix for
the number of mistakes and exceptions we're currently seeing in
the formatted fork!)
Now that I can finally build the docs locally I've started
making some notes of things that seem like they could use
clarification so I can submit some PRs to improve them.
I'm hoping someone can help me find information on a
couple of things:
What do all the various mouse buttons control?
As best I can tell:
button causes horizontal motion to rotate about the
y-axis, vertical motion pitches in a polar orbit (not
sure how best to describe that)
Right moves the pushes in or out on the lookAt
On OS X Option clicking lets you pan
around moving the lookAt point
a way to limit camera moves? Say keep the camera above the
xy-plane? Or prevent them from pushing back beyond a certain
Is it restricted to just using those axes? Is it
possible to orbit a different axis? Yes it is, it uses
the camera's initial world up vector as a basis for
rotation. So you can just assign an alternate value to
that before connecting the camera.
How do you get let the app handle mouse event ahead of CameraUi?
Rich points out that you can use a signal of -1 in this comment.
Could we explain what axes()'s parameters
mean? I wasn't familiar with the term axis-u and axis-v
so had to do some experimentation
Thanks Paul for the support , I really appreciate !
great , I want to use this wonderful framework , even the Cinder
community is less active than others C++ frameworks . Thanks for your
time , and sorry to asked an obvious question like this.