Jump to content

Guillaume Lessard

  • Posts

  • Joined

  • Last visited

Everything posted by Guillaume Lessard

  1. QUOTE(TobyD @ Feb 20 2008, 03:51 PM) That could get really old if what you want to do is look at the current block diagram. Currently anything that pops up is fairly small and non-intrusive. If LV starts popping (reduced) block diagrams whenever the mouse pointer is stopped for 2 seconds... I can feel a surge of annoyance already!! Pop it when a modifier key is down. Or show it in the context help window when a modifier is down. (Ah, the annoyance ebbs...)
  2. QUOTE(Aristos Queue @ Dec 13 2007, 01:21 AM) Well, then. I guess I'll try to make suggestions more often!
  3. QUOTE(Aristos Queue @ Dec 12 2007, 01:22 PM) The part where a new probe doesn't automatically add itself to the class is quite irritating in itself; having to dig for it, move it, and then convince it to be part of the class... honestly I find it quite an energy barrier! Also, popping up on a class wire and creating a new probe there is not exactly intuitive -- seems like a pre-LV8 way to do things. Why not have the option of creating a probe VI directly from the lvclass/project window? (In a related gripe, creating and editing the mnu file for a class pop-up palette is also too circuitous). Should have the option to create "probe" and "palette" in the same menu as "static dispatch VI" and "dynamic dispatch VI". I'll stop here, because my LV machine is not in running condition and I can't compare wishes with reality. I'm sure I could come up with suggestions if I sat in front of it and thought about improvements; right now I mostly just remember that I was frustrated with the process of writing a probe!
  4. QUOTE(Aristos Queue @ Dec 12 2007, 11:22 AM) Very good. Now why is it so hard to make a class probe? The reason we have the knee-jerk reaction of wanting to see object contents as a standard cluster is that it's rather painful to see the data. It's feasible, but it's a lot of preliminary work for someone who is just trying to learn LVOOP and understand what's going on! Helpful code-generation tools are needed! =)
  5. QUOTE(crelf @ Dec 12 2007, 09:42 AM) I completely agree with this. I wrote a GUI with multiple event loops and it rapidly turned into a nightmare. I converted it to a single event loop with message passing. Each tab (which represent modes of operation in my case) has its own message processor, and it just ignores any messages that don't make sense. The code is much more understandable now...
  6. Hi, It seems to me that the design paradigm for distributed control involves message-passing, not uber-global shared-variables. The shared variable is, first and foremost, a global variable. It's useful when slapping something together quickly, but it can easily become a problem for scalability. And scalability is the problem you're going after! Multiplying the shared variables for each door you want to control seems to be pretty much a no-go. With a single-mailbox system (one shared variable), how will you guarantee that each message is received? Will you leave each message in the mailbox for a minimum amount of time? Will you wait for a confirmation that the message has been read? What if one door-controller locks and never gets its message? If each entity in the system has its own "mailbox" that works without extra programmatic configuration (i.e. without having to add shared variables all the time,) you get the advantage of multiple shared variables with the advantage of the single-mailbox system. That's what you'd get with message-passing. It will probably be more work upfront, but once it works, it'll be done.
  7. QUOTE(Jim Kring @ Aug 24 2007, 10:18 AM) I agree with Tomi that it's not a good idea. People shouldn't have to relearn every concept under a new name just to find out that they already knew about it... QUOTE(Val Brown @ Aug 24 2007, 01:11 AM) It really doesn't make sense for NI to alienate and disenfranchise its long-standing, advanced programming community that has "come up" using dataflow. Why have dataflow-based programming precluded by enforcing classes? Val, have you even looked at LabVOOP? It's Dataflow! It's Objects! It's unique! It's, well, LabVOOP. I'm pretty sure LabVOOP did more to "alienate" and "disenfranchise" the users most familiar with OOP than any other group. Getting them to rally around it has obviously been a problem...
  8. I have used LVOOP in one part of an application as I was refactoring it. The result was a little messaging library that I found quite satisfying, and as a result I'd like to use LVOOP some more! I was expecting to be able to do so after the new version came out. However, the meat of my LabVIEW work involves the RT module, and so I still can't use LVOOP very much at all. That's very unfortunate.
  9. It seems that there are still no LV Classes in the real-time module, though. That's unfortunate! What are the reasons this is so?
  10. QUOTE(george seifert @ Jul 30 2007, 02:45 PM) You can send your data along to another, lower-priority loop using a queue. File operations are some of the first things to send to another thread if you ever have problems with code that hiccups...
  11. Relating to that, is there an easy way to edit that mnu file other than editing the whole palette? That's the only method I've found, and I must say it feels very very kludgey -- especially since I only want that class palette in the pop-up menu...
  12. Hi, I'm working on a little messaging framework to send data over TCP between two machines. That's simple enough, and I thought I'd save myself a bit of work when sending complex data types by converting them to variants and then flattening the variants to strings. What I didn't realize is that "Variant to Flattened String" doesn't really flatten into a string, but into a string and an array of integers. That doesn't really help for sending data over TCP, unless I cluster that up, flatten the cluster and send that. Ick. Is it necessary to use "Variant to Flattened String"? My cursory testing indicates that "Flatten to String" works fine for variants; I haven't found a case where it fails. Note that I'm not interested in using any of the fancy features of variants in this case. The online help and examples do not bother to go into the whys and wherefores, and so are unhelpful for this! Thanks for illuminating me,
  13. QUOTE(Tomi Maila @ May 29 2007, 11:13 AM) I fear this is mostly a rhetorical question; I doubt the answer would be interesting. Likely along the lines of "Because we could" or, at worst, "because of paranoia."
  14. QUOTE(Jeff Plotzke @ Feb 18 2007, 12:58 PM) I expressed myself poorly; when I was originally trying to figure out what architecture to use, I tried repeatedly polling a local variable tied to a button. That (kind of) worked, but it was very ugly. I ditched that solution because it wasn't very scalable, and in any case the front panel added jitter to my app!
  15. For a host of reasons including a similar one, I run my front panel as a controller running on the Windows machine and it sends commands via TCP to a VI running on the RT target. This also happens to get rid of jitter induced by the front panel on the RT machine. It adds some complexity overall, but at least you'll be able to use an event loop as well as all the latching behaviours you want on the front panel -- and that cuts down on complexity! I used a variation on an NI example, Simple TCP Messaging. The other thing I can think of is to go in a loop whenever the button is clicked, and then monitor the mouse button until it gets released, sending the appropriate commands along the way (presumably between pauses). It would be an uglier solution, but probably quicker to implement!
  16. I don't either -- thanks for the putdown. I do, however, value a performance higher than the idea of a performance. Between non-traditional performances, that of a great turntablist is much superior to an automatic-music performance-art installation because the human/natural input is more present. Similarly, being in a forest full of nature sounds is better than hearing a recording of those nature sounds. In music, performance rules.
  17. Really, I wasn't kidding. It might be a cool toy to build sounds, but to call it an "instrument" is farcical. What enabled synths to become useful was to plug them back in to the standard input devices!! I'm not saying that new musical instrument designs can't be achieved, but it's all about producing a good input device, not about getting any other feedback than sonic back to the performer. Incidentally, the most impressive "new" music-producing device I've seen recently was a re-wired Kinesis contour keyboard where keys mapped to intervals from the current tone, in a mirrored geometry. It has a silly name, the Samchillian Tip Tip Tip Cheeepeee, but don't let that deter you! See http://video.google.com/videoplay?docid=4889538176718826165. That enables the musician to punch in "keyboard" licks that sound like horn licks, and it's abstracted from the nitty-gritty, but not too much. For a track featuring that input device, hear http://www.samchillian.com/mp3/nytimessurp.mp3 (near the beginning.) BTW it was the highlight of my night when I saw Masque live, despite the fact that the band involves Vernon Reid, one of the top guitarists alive. IMO, the Samchillian is a truly new input device, *and it's designed for performance*. The reactable, on the other hand, seems a bit more like a toy offering a slightly new approach to producing automatic music... it's not on the same level as an instrument.
  18. It's an interesting toy, but what about it can't be done on a normal computer screen? Also, seems to me that traditional things such as pianos or saxophones have pretty tangible UIs and are more practical than this -- such as in allowing rapid dexterity to have a role. The widgets are too specific to be really useful for anything else than effects generation and automatic music... in short, this musician was bored by the demo.
  19. If disconnecting the signals doesn't change anything, maybe they weren't connected to begin with. That really is what your description sounds like. (I've done it many times, and was dismayed every time...) Check all your connections. Make sure you're connecting to the right pins. Make sure you amps are sufficiently powered.
  20. Thank you! I'd been chasing a strange race condition that was linked to these ambiguities. Switching to FP.State solved it. Awesome!
  21. As you found out, they both produce the same result. In terms of algorithm efficiency, though, using the 'sort' function is slower: The 'sort' function scales in time with array size n as n*log(n) This shuffling algorithm (the Knuth shuffle or Fisher-Yates shuffle) scales in time linearly with array size -- in addition to not requiring additional memory.
  22. Good point. If your decisions can be made a while in advance, you can effectively enqueue your laser states in the output buffer. Real-Time would only be needed if you don't know a few milliseconds in advance what your laser state should be. If you cannot calculate your state at time T any earlier than (T - 100us), then you do have an expensive project on your hands =)
  23. In general, they're not a big deal, but in id2x's case finding the coercion dots is necessary to fix code broken by shared variables! This is *not* an advanced user issue, it's basic functionality.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.