I'm working on a live music visualisation project, where I am using a particle stream to visualise each channel of audio (vocals, guitar, percussion, bass) which are each coming from a looper.
I have the visualisation aspects working - I do envelope tracking in a separate pd instance, send the envelope details via udp to my gem instance, which then uses that to vary the size and colour of multiple particle streams.
The problem I have is that I am trying to set the origin point of each stream, and they are either interacting or they are controlling the origin of a different stream. The part_velocity also seems to be having a similar issue.
Each particle system has it's own gemhead (which I init as say [gemhead 20] so each one is unique), but changing the XYZ for its [part_source 1 point] object seems to affect a stream that's in a different gemhead chain.
I have also moved it off into an abstraction, where I name its head [gemhead $0] and I am having the same issue.
This unanswered thread from years ago shows two other people having the same problem, but no answers.
Here's a portion of my main patch which calls the abstraction:
And this is the abstraction:
Am I missing something simple here, or is there perhaps a bug in that one of the part_xxx objects is not checking which gemhead list it's in? Note that there are other gemheads in the main patch, some have an argument, some don't, but they're doing other stuff.
Oh yeah, and input is welcome on the somewhat dumb-looking way that I'm preserving state here, I've NO idea what the patterns are here, and cannot for the life of me find any good advice on it!
Related
I'm implementing a model in which many transport (Transport fleet, Material Handling library) move in the same network.
I've got some limited access paths ( limited to 1 transport).
The intersection between two or more path are nodes; in this way if a path is already occupied it will stay in the node until the path is free again.
The model seems to run until some transport get stuck (see screenshot).
At the moment Transport are able to resolve collision, but if the Resolve collision parameter is false then when transports get stuck a collision is detected.
I think transport cannot choose who can be the first to can cross the path (my thought, any suggestion is appreciated).
It is not a constant problem, it can happen at different times of the one year simulation or not happen at all.
What's the problem? How can I solve it?
Thanks
Transport stuck image
The problem is that the underlying algorithms cannot possibly work for any situation or foresee any eventuality.
Either you use the build-in resolution or you have to apply custom intelligence, route-finding and decision-making, which is possible but not trivial :)
I'm new to SUMO, Veins, OMNET++ and simulations with a bit background of networks. I have successfully setup environment and run veins 4.6 demo application. On google found that unlike RSU, Car modules are added on the fly.
In demo example car nodes send Airframe11p message, i'm not getting where this message is being populated because in TraCIDemo11p.cc methods (onWSA, onWSM, handleSelfMsg, handlePositionUpdate) we are dealing with WSM message types and BaseWaveApplLayer::checkAndTrackPacket methods ensures that message being sent is either BSM, WSM or WSA.
In veins\src\veins\modules\messages AirFrame11p.msg file exists but on finding references of "AirFrame11p" in project, matches are found in AirFrame11p_m.h and AirFrame11p_m.cc only. If demo is not using these files then for what purpose these files are added? and from where simulation gets the annotation of AirFrame11p.
I'm trying to simulate a car accident scenario without RSU using V2V communication, have replaced demo map with mine, generated random routes, now trying to remove RSU from demo application and exploring to send customized messages (including geo location, speed, direction, time etc) to nearby vehicles in specified range e.g. 100 meters using WiFi direct.
If i'm confusing something then please guide me. Thanks.
The short answer: The AirFrame11p message is a lower level message that encapsulates the upper layer messages. Just use the application message type that is appropriate for your application. If you want to replace the physical layer with WiFi direct instead of 11p, and you're starting from scratch, you're probably in for quite a bit of work, since the VEINS PHY implementation is very intricate. If you have an existing implementation of WiFi direct, it may be worth investigating the integration of VEINS' TraCI implementation with that code.
Encapsulation in VEINS
You are correct that the message types at the application layer are more diverse -- these message types (BSM and WSM) are used to encapsulate "application" behavior; it's just not very well visualized in the simulation execution. You can pause the simulation and look (for example) under scheduled events, where the queued packets can be examined visually.
Unlike regular networks, where such messages would be packaged in IP, MAC and PHY encapsulations, VEINS uses the following encapsulation process: BSMs are packaged in MAC frames (80211Pkt), which in turn are encapsulated by AirFrame11p signals. So basically, you should choose the correct message type for your application.
Footnote regarding application behavior:
Technically speaking, these messages would be more correctly placed at the Facilities layer (see e.g. ETSI's spec), since the periodic exchange of messages provides data stored in the facilities layer, which is then used by cITS/VANET applications that run on top. If you need this, look at Artery (as Ventu suggested in the comments).
I have a simple UDP server that I'm going to use to make a game you can play on your LAN. Here is how I want my game to run. I have, let's say, 5 players. All players have a x and y position. These to values are given the the host. On the host machine it assembles all these x and y positions into an array. It then blits these players onto a pygame subsurface. I want to then give the clients the updated map so that all they see is the players updated positions. My main concern with all of this is how do I convert the subsurface into a transferable data type so the client can receive the encoded data and decode it then print it to their screens.
I don't believe you'll need any code because my question is not specifically aimed at my code but if you do let me know. The only problem with supplying you the code is only bits of it are working as of now and the little that is won't help you much.
Just for anyone in the future I found the answer to my question. It is simply encoding the image to base64 transferring it then decoding it.
However sending the array formatting and reformatting proved to be more efficents
I was working on a Simulink model recently and was using Goto and From blocks to keep a very busy system from becoming a twisted mess of wires. I was informed that I was not to use Goto and From blocks as they are considered bad style (at least, according to my employer).
While I hold that wires should be kept connected whenever possible, I believe that Goto and From blocks can significantly improve the readability of a system/subsystem if the model would result in lots of crossed wires otherwise; especially if the blocks can be color-coded (e.g. purple Goto block goes to all the purple From blocks).
I'd supply an image of the subsystem I'm working with, but I'm not sure I can put it on here. The subsystem itself has about 12 subsystem blocks (and possibly more later) within it, each with two bus-type outputs. The first output of each subsystem goes to a Bus Creator block, and the second output of each goes to a second Bus Creator block. Since the subsystem are aligned vertically and the Bus Creators are to the right, this results in many crossed wires. I was using Goto and From blocks to clean up the system.
I can supply an image of a smaller, but similar model that I put together for this question.
For a system with on the order of 12 subsystems, this becomes very busy. I was using Goto and From blocks to connect the subsystems and the Bus Creators without a plethora of crossed wires.
I believe my employer may be carrying the stigma of using goto statements from text-based languages and applying it to Goto/From blocks in Simulink. Generally speaking, is using Goto and From blocks in this way (or any way) considered to be bad style?
The Mathworks Automotive Advisory Board has published some modeling guidelines (PDF) that include usage of Goto/From. The rules they list are:
Do not have subsystems that are floating, i.e. all inputs / output ports are connected via Gotos. One of the great things about Simulink is the ability to determine signal flow with only a cursory visual inspection, do not destroy this by linking everything with Gotos. At least have one feed-forward and one feedback loop between subsystems connected by signal lines.
My personal opinion on feedback signals is that they should all be connected with signal lines, but I'm sure you can come up with cases where drawing all of them clutters the model.
The second guideline is about the scope of the Goto tag; keep the visibility local as much as possible.
I feel setting visibility to scoped is acceptable also as long as you're not using the matching From more than a couple of levels downstream from the Goto. I've yet to come across a legitimate need for a global Goto tag.
So, all Goto usage isn't bad, and you're right that it can improve readability in some cases. That being said, I don't think Gotos are justified for the picture above. I realize it is just an example, but I should point out that if the buses being created are virtual that order of the inputs at the creator doesn't matter, and rearranging Bus Create and Mux block inputs can work wonders for readability.
The problem with the guidelines above are that there's room for bending them, and developers on your team might do just that. Even if everyone is diligent about following them at first, you may run afoul of these guidelines one day, a long time from now, when you redraw that section of the model for refining / adding functionality. Rearranging inputs and outputs can be especially irritating in middle of implementing some cool new feature. That may be the reason your employer chose to impose a blanket ban. It is inconvenient in some cases, but is easier to enforce.
I want to write GUI code that is orthogonal. Lets say I have a circle class and a square class and they need to interact. Right now, to get the circle and square talking to each other - say the circle object sends a message to the square object, I would use something like square_obj.listen_for_circle(circle_obj) where listen_for_circle is a method that implements an addlistener.
This is a problem for me since now the two objects are linked - and removing one object from my code would break it. What I am looking to do is for the circle_obj to be able to broadcast a global message say 'CIRCLE_EVENT'. Additionally square_obj would be listening for global message broadcasts of type 'CIRCLE_EVENT', and upon hearing the event - does some action.(Ahhh, now the objects have no links to each other in the code base!)
Is this possible or even reasonable in MATLAB? (or maybe i'm just going crazy).
As always, advice much appreciated.
I'm not really sure why addlistener is problematic for you. It basically just adds an event listener that doesn't do anything if the event-origin object (the circle) is deleted.
Alternately you can use event.listener or handle.listener. They are undocumented but work well, and are widely used within the Matlab codebase (m-files). See explanation here: http://UndocumentedMatlab.com/blog/continuous-slider-callback/#Event_Listener