Marking Menus [1], Pie Menus, Radial Menus and friends have been around for a while. There is good body of research on them, with some recent research done on their use in multi-touch environments. [2]
While working at DreamWorks, I would often watch artists navigate complex marking menu hierarchies and invoke a command before the menu items themselves could actually be read by a non-trained user. In our custom lighting tool, you could execute the marking menu command by invoking the menu command and making them mouse movement before the menu actually drew.
It was used in some games to great effect as well, e.g. Neverwinter Nights. Same story there - once you memorize where the commands are, each invocation effectively becomes a mouse gesture performed without even looking at the bubbles.
John is cool, but I don't think he was around when the Macintosh II software and hardware was being designed for color support. I did work with Eric Ringewald at Be and he was one of the Color Quickdraw engineers. He would be fun to talk to. Michael Dhuey worked on the hardware of the Mac II platform. I guess we can give some credit to Jean-Louis Gassée as well. Try to talk to those people! I got to work with a lot of these Apple legends at General Magic, Be, Eazel and then back at Apple again. I never got to work on a project with JKCalhoun directly, but I did walk by his office quite frequently.
True. I showed up at Apple in '95 after Color Quickdraw was already a thing.
Hilariously though, I did get handed the color pickers to "port" to PowerPC. In fact one of the first times I thought I was in over my head being at Apple was when I was staring at 68030 assembly and thinking, "Fuck, I have to rewrite this in C perhaps."
From your username, I feel like we've chatted before (but I don't know your real name).
There was quite a bit of discussion about this a couple of years ago. OpusModus[1] investigated supporting CCL on M1, but wasn't confident that it could be accomplished, and instead ported their product to LispWorks.
There are numerous symbols to represent pitch on a staff, numerous other symbols that can be attached to the pitch symbols that represent changes in duration, dynamics, various techniques and more. These symbols can be stacked above and below the pitch symbols, to the sides of the symbols and more. There are other symbols that can span multiple pitch symbols, groups of symbols and more. There are more symbols that control the tempo of the playback of the score, the number of times sections of the score should be repeated and other symbols that will move the current playback location of the score to some other place. The placement of all of these symbols have "rules" but these rules are really suggestions and composers will always want to adjust and bend these rules. If a system implements strict rules, that system will come under criticism as being inflexible. There seems to always an exception to every rule of music notation.
I have been working on music notation software for almost forty years and have seen programmers come and go with their attempts to "solve" the problem of music notation. It is a very difficult problem. Once upon a time SCORE [1] was considered the best of the best on music engraving software. I worked with Leland Smith to update the program to more platforms. Sadly, the SCORE source code is not available and the rights of the source code are unclear after Leland's passing. Many music publishing companies continued to maintain systems using SCORE for quite a while.
The notation engine of my iOS music notation program Komp [2] is available here: https://github.com/SemitoneGene/notation. This code is most certainly not the best or most complete, but it is easy to read and comprehend if you want to see the complexity involved. MuseScore has also been mentioned in other posts.
If I were to do a commercial engraving of a music score, I would use Dorico. It is being developed by who I would consider the most insightful and understanding group of developers who have a real desire to make the best music engraving program.
LilyPond produces very good output but offers its own series of challenges to use. MuseScore is a nice program, but it has a long way to go to meet the demands of the high professional composition and engraving market.
This is an obnoxious response that has no bearing on the content of the article. You may as well state that cancer is caused by not praying to the god of your choice or by not following some specific 12-step program that you have deemed vital.
There is no truth to your statement that is it not socially acceptable to suggest diet and lifestyle changes to improve quality of life. Those suggestions are made all the time and people who suggest them in general suffer little to no negative consequences. I am not sure how you go about making those suggestions, but perhaps your approach is less optimal. There are situations where suggestions will be made and go unheeded. Many alcoholics know that drinking is bad for them and many smokers know that smoking is not having a positive effect on their health. They choose to ignore the advice.
My wife, who passed away almost two years ago, received CAR-T therapy for triple-hit large B-cell lymphoma. I can assure you that her diet and lifestyle choices were most likely not the cause. CAR-T therapy is not made available to any and all and her case was most likely caused by exposure to specific toxic chemicals. I only wish she would have survived the extremely toxic and negative side-effects of the therapy so she could be here to reply to your comment.
I assume he would say the same things I would hear him say in meetings where the installer team would show him the lastest versions of the application. A special memory comes from the time where the installer progress bar starting going in reverse. The installer and mail teams received a lot of abuse. It took a special person to stay motivated given all of the challenges they faced and the feedback they got from SJ.
As a customer (my personal computer/display/phone/etc spend with Apple over the past 20 years or so: $25k+): I would prefer having someone in charge who can tell/understand/sense and say that something is clearly not good enough and then actually getting it solved. Tim Cook does not strike me as that kind of guy.
Stan and I worked together at DreamWorks Animation and I kept in touch with him after we both moved on. At DreamWorks, Stan was dealing with some difficult problems such as moving our code from 32 to 64 bits.
It is inevitable that Stan will be remembered for the C++ Primer. When being introduced to Stan, some percentage of people would recognize his name and ask about the book or some other aspect of C++ history. Stan would kindly respond, but I always got the sense that there were other things he would rather discuss than time spent with Bjarne in front of a whiteboard or dealings with various standards bodies.
Stan was complicated and complex. I feel that he would much rather be remembered as a father, an artist, a dancer and a lover of beauty. We usually can't determine how we will be most remembered, but Stan's work on the C++ Primer, while important, is low on my list of memories of him.
I am an adult who has built several Lego kits recently. These include the NASA Saturn rocket, the NASA LEM, a grand piano and a Fender guitar amp combo.
The plastic parts are more than just generic shapes; many of them are custom and designed for the specific kit. The plastic itself has a good feel and is durable.
The kits are unique and must have required numerous hours of research and development, prototyping and user testing.
The documentation is extensive, high-quality and complete. In addition to the instructions, there is nicely researched and presented material about the subject of the model.
If anyone is reasonably able to come up with a process to compete with the sum total of all of these elements, I wish them luck. I would also like to invest!
> The plastic parts are more than just generic shapes; many of them are custom and designed for the specific kit.
With Lego, it's surprising how often the parts are NOT designed for a specific kit.
You can look through the parts list at the end of the instruction manual. You'd be surprised how often they've re-used parts you'd think are specific to a kit. With Saturn V in particular, I was SURE the fairing must be a part specific for that kit. Turns out it's the spire from a Hogwarts castle kit. Okay, so that's the only other kit it was used, but still..
If you look at clone kits, they often have more kit-specific parts. I think this is counter-intuitively a part of a strategy based on low-cost. They spend less on extremely precise plastic molds, and designing a kit-specific part can make it easier for designers. They don't have to spend a lot of time thinking of creative ways to re-use existing parts. They don't need to have knowledge of obscure parts they could re-use either.
> The documentation is extensive, high-quality and complete.
And it's easy to find them online if you've lost them, and you can easily find missing parts of bricklink. So you can dump all your Lego in a box, save it for your kids, and be sure that they can still be used, and that you can rebuild the sets if you want.
I saved my Lego from my childhood. I recently took them out to play with my kids and they're still perfectly good. The only thing that doesn't match with modern Lego is the electric stuff.
> With Lego, it's surprising how often the parts are NOT designed for a specific kit.
OK, that is interesting.
I wonder if and or what the software used by kit designers looks like? Does Lego have a custom CAD system that references the catalog of existings parts? Are they any Lego employees here that are able to comment?
unfortunately we dont support full remote. but offer a nice relocation package. we hire for software engineers in Billund, Copenhagen and London, we have hired 1000+ last 2 years, massive digital growth
I was on a quest to find the Super Foonly for several years in the early 2000s. I never got close to finding it, but did uncover several treasure troves of documents from the early days of computer graphics companies Omnibus, Digital Productions and Robert Abel and Associates.
I think it was Larry Yaeger [1] who suggested that the collapse of Omnibus meant that a lot of the equipment in the DP machine room was sold or scrapped.
Not that I'm going to try a similar quest, but how does one go about starting one? Just send as much mail, email and forum posts as possible, inquiring to every person you can get the name of?
How did you all at Ann Arbor (I assume) get into Mac development? Did you have Lisa versions of software and decided to move to Mac? Did Mike Boich or Guy Kawasaki convince you to start developing? I am always interested at what makes someone decided to pour resources into a new platform. I have done it more than once myself and it is usually very high risk.
I don't think we ever developed any software targeted at the Lisa (or if we did, it was in the brief period before I joined). We were always developing for the Mac, initially cross-compiling from Lisa.
We did move to Mac-based development after not too long. I have zero memory of why/how that happened, but I'm sure it was clear even at the time that the Mac was the more sustainable long-term platform (also the Lisas were insanely expensive). Still, for a while there it was a real stretch to squeeze a reasonable dev environment into Mac hardware. I remember – and this feels insane as I'm typing it, but it happened – at some point we actually paid someone to fab an add-on circuit board that we somehow glommed into our Macs (these were probably 512KB or 1MB models, I can't remember) that doubled the RAM size. The additional RAM couldn't be used for normal applications, it somehow manifested as a RAM drive. We had one RAM drive in the add-on memory, a second RAM drive partitioned from the standard motherboard memory, and the rest of the standard memory was used to run dev tools and/or the application under test. Putting all of the source code into a RAM drive was necessary to make the development experience tolerable (I can't remember whether the concern was source code navigation, build times, or both... EDIT now that I think about it, it might have been the object code rather than the source code that needed to be on the RAM drive; or perhaps both).
In the mid-late 1980s we compiled and tested Amiga software on the Amiga entirely from RAM drives using rather expensive 2 MB RAM add ons, and then stored the updated source code on 3.5" floppy disks that had to be rotated out regularly because they regularly went bad.
Only towards the end of the 1980s were hard drives inexpensive enough to become commonplace. My first 65 MB drive cost $949 (ca 1989), and that is why we were using floppies and RAM drives instead. The RAM drives did survive reboots and crashes most of the time, which helped quite a bit as you may imagine.
While working at DreamWorks, I would often watch artists navigate complex marking menu hierarchies and invoke a command before the menu items themselves could actually be read by a non-trained user. In our custom lighting tool, you could execute the marking menu command by invoking the menu command and making them mouse movement before the menu actually drew.
1. https://www.billbuxton.com/MMUserLearn.html 2. https://damassets.autodesk.net/content/dam/autodesk/research...