Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
- Subject: Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
- From: Richard Burnett <email@hidden>
- Date: Tue, 20 Jun 2006 15:58:22 -0400
>I should have been more clear. In the instance where I pass data to
>the AU from the UI, the structs are allocated and filled out in the
>UI. I then pass a pointer to them in AudioUnitSetProperty. When I
>get the corresponding call in the AU, I copy the data into a local
>struct in the AU. It works flawlessly in my experience. Sorry for
>adding any confusion.
Okay, I understand now, that makes a lot more sense. Yes, I am guilty of passing pointers back out of the AU into the UI and calling them from within the UI. I mainly did this because it made my code quite simple. I am going to have to rethink how I am doing certain updates. Basically, this was the issue:
1.Slide a slider in the UI
2.The action pushes the new parameter to the AU
3.I called a function in the AU to update the LFO class
4.I redrew the LFO waveform (called display on it, custom class).
I had previously used the property to pull the instances of the LFO class to the AU.
The correct way to do this I am assuming is to pass a structure holding the data locations I need that is in the UI namespace and call the property at step 3, then redraw using the details in the struct in the UIs namespace.
>On the other point of VNC vs. X-Windows, can we please stick with the
>architected solution? For one thing, what to do if the processing
>node has no UI capability at all?
How would you execute the code on a node if it didn't have the OSX frameworks already there? I think the 'vnc' example isn't quite clear. There are two ways to run VNC. You can have it copy the whole window that is up (like in Windows or OSX) or have it run without a local display (vncserver) with it's own internally running window server. A machine does not have to have local UI capability to run a vncserver as long as it can run internally.
>What if the processing node is
>actually a collection of nodes controlled by one UI? It seems to me
>that the current solution can work in either of these situations (and
>many others) with no problems. We just need some hosts to do it.
>rob
I don't see a difference in ability. With the mentioned 'vnc' approach, the rendered screen is handled internally. HOWEVER, I see part of what you are getting at. Even if you don't have a UI available on the other machine, you have to have some kind of system running on the node to handle all the UI ability and rendering (even if internal). With the suggested solution, tht UI runs on the host and wont add any other overhead UI wise to the nodes. So I agree. :)
Rick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden