Hi all,
is there a way to export a bpf-lib (and not only a simple bpf) to svg? Moreover, if someone has figured out how to import svg as a bpf (or a bpf-lib) it would be great news too. Thanks for your kind attention.
Best,
Francesco Vitale
Hi Francesco.
Here’s some code which exports all paths from a bpf-lib to one svg.
I’ve removed the various formatting arguments to svg-export (width, height, margins…), as they edit the numerici values before export, and i can’t see how they make any sense in the context of an svg. Kept the flipping of the y-axis however.
I’ll add the method for bpf-lib (with the changed arguments) in OMs core, unless someone cries out loud.
-anders
export-bpfs-to-svg.lisp (3.32 KB)
Forgot the import part 
There’s code in “externals/XML/xml-api.lisp” to parse xml-files.
You can use (oa::om-list-from-xml-file “myfile.svg”) to get the xml structure as nested lists, then just dig through to pick whatever you need using standard list programming.
Dear Anders,
I cannot thank you enough for your precious help. I’m trying to use your .lisp file, which I have located in the “patches” folder, but I have this error that immediately pops up whenever I try to start OM: ERROR: Lambda list (SELF FILE-PATH &KEY :WITH-POINTS) is not congruent with the lambda list (SELF FILE-PATH &KEY WITH-POINTS W H MARGINS LINE-SIZE) of #<OMGENERICFUNCTION EXPORT-SVG 40E0BBEC74>. Maybe there’s something wrong in the lisp code you kindly gave me? Thanks again for your support.
Best,
Francesco
Nevermind Anders,
sorry for having bothered you: of course, my mistake was having not replaced your code in the “basicproject” file “export-svg” (putting the .lisp in the “patches” folder was wrong). Now everything loads without any error. Thanks for all.
Best,
Francesco
Sorry, that was clumsy, sending along a file with incompabilities in :-/ Changing the arguments of an existing method makes lisp whine. Putting them in 01-basicproject will probably hit other problems.
Just add the missing arguments back again in the lambda list of the two methods, then lisp will stop complaining. Ie. something like this, for each of the two methods:
(defmethod* export-svg ((self bpf) file-path &key with-points (w 300) (h 300) (margins 20) (line-size 1))
and
(defmethod* export-svg ((self bpf-lib) file-path &key with-points (w 300) (h 300) (margins 20) (line-size 1))
Sorry for the bother. I’ll change the code, but then you’ll have to wait for the next release.
-anders
Which ‘patches’ folder are you referring to?
Dear Anders,
the “patches” folder I mentioned before is the one no longer visible in OM 6.13, but it still present in OM 6.12 (the version I’m currently using). It appeared along with the “code” and the “libraries” folders accompanying the OM app.
Now the code I have stored in the /Applications/OM 6.12/code/projects/basicproject/functions/file.lisp, according to your new rewritten lines, is arranged like in the .lisp here attached, but evaluating the export-svn object all I get is always the same message: No method is defined for these types in box EXPORT-SVG. So maybe there’s something more that needs to be adjusted…
Best,
Francesco
Hi Francesco. Use the attached file, and make sure to place it in you “patches” folder, not in basicproject.
The next release will have this support built-in, so please delete this extra file from your workspace if/when you upgrade.
export-bpfs-to-svg1.lisp (3.53 KB)
Hi Anders,
shall I restore the file.lisp in /Applications/OM 6.12/code/projects/basicproject/functions/file.lisp to its original form, or keep it modified (like in the file.lisp I attached to my previous message)? I’m asking this because the “No method is defined for these types in box EXPORT-SVG” keeps appearing even with your new code (the export-bpfs-to-svg1.lisp file) in the “patches” folder. Thanks for your patience.
Best,
Francesco
I tried also with the original, unmodified file.lisp in /Applications/OM 6.12/code/projects/basicproject/functions/file.lisp and your export-bpfs-to-svg1.lisp but the result is the same: cfr. the attached screenshot
You’ll need to connect the leftmost output from your bpf-lib into the export-svg box.
Use the original file.lisp, and put the second (last) version of export-bpfs-to-svg.lisp i sent you in you “user” or “patches” folder.
Thanks Anders,
now I can evaluate the export-svg object, but the resulting svg file is blank! I attach here the .omp and the output file. Am I doing something wrong again?
Patch-7.omp (2.02 KB)
Your patch works here.
There’s already too much confusion from this thread. You’ll need to rewind back to zero. Make sure to:
- quit OM
- delete all versions of export-bpfs-to-svg.lisp or export-bpfs-to-svg1.lisp everywhere
- take care that the file "functions/file.lisp" is back to the original coming with your OM release
- start OM
- open the "Lisp Editor" (from the workspace: "Windows"->"Lisp Editor")
- download the attached file
- copy/paste the content of the attached file in the Lisp Editor
- Eval the buffer (Ctrl-Y)
Check your patch-7 again.
temp-bpf-to-svg.lisp (3.53 KB)
Ok Anders,
I’ve followed your instructions carefully, and this is the OM Listener output that results from
- evaluating the buffer of the Lisp Editor with the code contained in temp-bpf-to-svg.lisp and
- evaluating the patch-7:
====================
OpenMusic v. 6.12
r. 2018/04/24
© IRCAM - Representations Musicales
http://repmus.ircam.fr/openmusic/
====================
OM > #<The OpenMusic package, 18315/32768 internal, 425/1024 external>
OM > with-svg-scene-to-file
OM > #<ommethod export-svg (bpf t) 41601EFC5B>
OM > #<ommethod export-svg (bpf-lib t) 41601F1AC3>
Loading patch: /Users/francescovitale/Desktop/workspace1/elements/Patch 7.omp
OM => #P"/Users/francescovitale/Desktop/workspace1/out-files/Untitled.svg"
Of course all versions of export-bpfs-to-svg.lisp or export-bpfs-to-svg1.lisp have been deleted everywhere and the "functions/file.lisp” is the one coming with the OM 6.12 for OS X (I’m on El capitan).
Sadly the svg file is still blank. Now I really don’t have the slightest idea about what could be the issue right now…
Hmm, this was a hard one, but let’s continue until we get it working.
Your “Untitled.svg” is not empty (check in an editor). But for some reason the coordinates are written to the .svg-file using an explicit single-float floating point representation:
path d="M0.0F0 100.0F0…
which is used inside your bpf, and is fine inside lisp, but not compatible with the svg spec.
The cl-svg library used internally in OM uses “~A” to format the numbers to the svg-file, which should yield the wanted representation.
I have no idea why this occurs in your OM/machine (works fine here with your Patch7.omp). Could you do a test: in your Lisp Editor, try to enter (princ 0.5F0) and send me what is printed out in the Lisp Listener?
Well Anders,
thanks to your insights I found and resolved the problem. For an unknown reason, OM formats by default the floats with the “F0”, and I had to use the command (setf read-default-float-format ‘single-float) to get a standard readable svg. By the way, the “F0” floats issue in OM is very annoying for all kinds of data managing, and if someone finds a fix to get the command (setf read-default-float-format ‘single-float) by default when starting OM it would be surely great. Thank you again for your indispensable help.
Best,
Francesco
'single-float is the default for read-default-float-format in CL, and should be so in OM as well.
Please send me the value of read-default-float-format after startup in your OM. Also, what does this print to the listener:
(read-from-string “(1.0F0 0.112233445566778899 1.0e0 1.0s0 1.0f0 1.0d0 1.0L0)”)
Thanks,
-anders
Dear Anders,
sorry for the late reply. As I suspected, the default here (on each of my computers, i.e. a MacBook Pro, an iMac and a MacPro, with different OM versions) is the double float, in fact:
OpenMusic 1 > read-default-float-format
double-float
The second output you requested by consequence is:
OpenMusic 2 > (read-from-string “(1.0F0 0.112233445566778899 1.0e0 1.0s0 1.0f0 1.0d0 1.0L0)”)
(1.0F0 0.1122334455667789 1.0 1.0F0 1.0F0 1.0 1.0)
58
None of the standard omlibraries set the read-format permanently to double-float, and OM for sure does not. Either it’s something in an init-file you’re loading, or you’re loading some other software into OM changing this globally.
Check with a ‘clean’ OM, ie. no libraries, and add things back while peeking at the value of read-default-float-format to find the sinner.