Exporting SVG from Illustrator
  • Screen Shot 2017-09-01 at 10.08.23 AM.png
    659 x 372 - 39K
  • IMG_0001.jpg
    2552 x 3508 - 896K
    Screen Shot 2017-07-07 at 1.03.38 AM.png
    716 x 556 - 134K
    Screen Shot 2017-07-07 at 1.03.29 AM.png
    524 x 414 - 78K
    dog test.audulus
  • Thanks for the tip, I'll definitely try this out!
  • I suspect you may have exceeded some internal limit in Audulus. At first I thought your image was an embedded raster, but I opened it up and it actually contains a fairly large number of individual paths. In terms of file size it's almost twice as large as all the images I've done combined. That said, It still looks pretty good even with the missing bits. (I had to play the "What's missing in this picture?" game to see what had been left out).
  • After looking at it in Affinity designer I noticed that the nose and ear with missing parts is one large path and uses the "even-odd" fill rule to get the detail in the nose and ears. I bet that Audulus doesn't handle this type of fill properly. Probably only does solid fills.
    dog nose.svg.zip
  • @stschoen Interesting. I wonder how best to consolidate the objects to remove even-odd filling. Well for the time being it looks like i will have to redraw the images as I was overall disappointed with the degree of tracing Illustrator was able to do to the original.
  • @stschoen I just noticed that the letters that say "option click to load svg" when you are loading an svg have the same problem you describe where the "o" and "p" etc. have their enclosed negative space filled in. At first I thought it was a stylistic choice. Now I see it as probably a bug... or a forced design choice. It's so hard to tell sometimes.
  • I suspect Taylor used an existing library to render the elements of Audulus and most likely they're coded in SVG. The SVG node was probably a "freebie". It's likely a limitation of the underlying library. In this case, rendering performance would have been by far the most important consideration. Lack of an even-odd rule wouldn't have an impact on the style of graphics used natively. It's been fun to play with with the graphics, and they can certainly be useful, particularly in a multi-national context, but one of the things that really attracted me to Audulus was the elegance of its UI design. I think we'll need to be careful not to get too carried away. As far as I can tell the additional CPU load caused by using the SVG node is minimal, but in the end it's all about the sound. That said, I think I'll do some more work on my fuzz-face copy LOL.
  • I would frame it as being about the experience, encompassing the the sound and the challenge of designing the user interface. With the dog, I was just seeing what the limits are. I like the aesthetics of guitar pedals and crazy eurorack modules, but I can understand how that might not be for everyone. Perhaps I will make "clean" versions of modules I deck out with drawings, but by the same token it's not hard to delete illuminated elements from your personal library.
  • I certainly didn't mean to discourage your creativity. Since deleting the graphics is so easy, I say decorate to your heart's content! I was quite impressed with the dog. I was thinking about it and you might be able to create the unfilled areas as independent shapes and layer them on top. I used that approach with the little keyboard I made and it seemed to work fine.
  • @stschoen Most of the UI is actually just coded by hand, because sizes and shapes vary. Currently, only the icons on Input, Output, Mic, and Speaker nodes use SVGs.
  • @Taylor, thanks for the info and for including the SVG node. @RobertSyrett and I and others have enjoyed decorating the Audulus UI. Hopefully it brings a bit more clarity and a bit of fun to Audulus. Thank also for staying with a consistent set of sizes for the UI elements. It makes creating the graphics much easier. I really appreciate all the hard work you and Mark have put into this project and if there is anything I can do to help, please let me know.