What's the competition got that we don't?

[stavro]

Just wondering whether GVOX was in need of extra developers? And if so, I would like to put myself forward. What programming language is Encore written in? I am a programmer myself, one of those rare souls who is both technical and musically inclined. My code is always fast, well implemented and thoroughly commented for others on the team should they be working on the same module. Just an idea only.

[stavro]

I believe this has already been mentioned on this thread, I was just wondering when can we expect the proper import of graphics? From Finale:

[q]

I believe this has already been mentioned on this thread, I was just wondering when can we expect the proper import of graphics? From Finale:

Thanks stavro!

Your lovely example clearly illustrates of the powerful impact of graphics!

Many of us want to import various types of graphics, so we can include charts, instrument images, theory diagrams, and music symbols not available in Encore ... and also to be able to display logos and other branding graphics. When the time comes, hopefully we'll get a wide range of image formats. Maybe even SWF.

Although your example includes no direct overlap of notation and graphic, it certainly underscores the importance of placing one or more images as background — alpha transparency is quite important for such purposes!

q

[stavro]

Thanks for the compliments q, although I cannot take credit for the sample picture which I found whilst browsing other competitors websites.

It’s true, the simple addition of adding a graphics import ability, even just EPS for now (and we would use other software to get it into this format) would enable a whole new world of possiblities, and ahem, workarounds!

As regards alpha-transparency, not so difficult to implement at all these days really. Of course I don’t know the underlying structure of Encore code (could be a bit dated), but I believe Matt has already mentioned that he is using GDI+ now on Windows which makes it easier than one might otherwise expect. I know so... I’ve done it on several programs when I was doing more programming a few years back. I'm not familiar with the Mac OS X API, but I bet it's even easier.

[polarbreeze]

It occurs to me that if I were creating a book similar to this example, I would do it with a desktop publishing program and I would import the score element as a graphic. This is the opposite direction from using the notation program to import the graphics elements.

Don't get me wrong: I do definitely support the idea of having graphics import in Encore - and also, by the way, a properly structured text object capability. But I think there are limits as to what it really needs to do. Developing desktop publishing features in Encore could be a major rathole and divert GVOX resources away from perfecting the notation aspects of the product.

Just a thought...

[Rob M.]

... But I think there are limits as to what [Encore] really needs to do. Developing desktop publishing features in Encore could be a major rathole and divert GVOX resources away from perfecting the notation aspects of the product.

A good point. While I don't want to rain on anybody's parade, it also occurs to me that if Encore ends up with all of the features that Sibelius and Encore offer, it would be reasonable to expect it to be priced comparably to those products. That's not what I would like to see.

One of Encore's strengths is its concentration on core features in a good notation program, as distinct from tossing in a lot of features that many users find no need for or can't accommodate in other ways. That concentration on core values is one of the things that makes Encore easier and more intuitive to use than either Sibelius or Finale. I wouldn't want to see Encore lose that intuitiveness.

But then, if the ability to import graphics can be done without sacrificing ease of use or diverting developer resources from the core features, what's to object to?

[q]

if the ability to import graphics can be done without sacrificing ease of use or diverting developer resources from the core features, what's to object to?

Plenty of good design patterns exist for inserting graphics, for adding background images, and for adding master page items. This means ease-of-use already has been pioneered, and many people are already familiar with the basic concepts. Additionally Gvox is clearly dedicated to preserving Encore's ease of use, and to its credit, Gvox has not complicated Encore's interface while developing Encore 5.0 for Windows and Encore 5.0 for Macintosh.

While I wouldn't want to see Encore's development indefinitely stalled for the sake of imported graphics, there are significant limitations to the present workaround: i.e. importing score PDFs into a page layout application. For instance, when the user changes an Encore source score, it's a challenge to keep a book up to date ... because PDFs embedded in page layout document are not automatically updated.

I don't think this workflow issue can be easily addressed. Revision and file management issues arise with project assets, even when the layout application links to external rather than embedded PDFs.

For simple projects I'd much rather place graphics directly in Encore.

Encore will surely garner attention and respect by supporting eye-catching results, like the example that stavro posted.

q

[stavro]

Thanks for your comments Polarbreeze and Rob, I find myself almost converted to your way of thinking, except that q put my side forward quite well I think.

Gladly, the general consensus here is unanimous though, that is to say that provided Encore doesn't require a monolithic overhaul of program code to achieve an import of graphics objects then we all would like to see this new feature.

I totally appreciate the focus being on perfecting notation first, but at some point there will have to be a step made to implement this. If the present implementation is dated, then there also exists a danger of expanding the code to such an extent that you reach the limits of what it can realistically do without a total rewrite. I think I would just like to know a plain answer from Matt as to whether a graphics import is a big task in the current program foundation. If it is, I will not mention it again.

[q]

  
Many people have requested 'facing pages.'

I'm all for facing pages, but additionally, how about an option for opening as many windows as you want, not as separate score documents, but as independent views (i.e. editable instances ) of a single score?

Imagine viewing linear and page views simultaneously in separate windows! Much like we have now with multiple instances of the same file, but where all views update a single score file.

This would allow the user to monitor remote areas of the score, and copy/paste between them, without the need to scroll or change pages.

q

[commnthings]

Yeah! That is one of the best ideas I've heard in months. I heartily second that motion.

Bob

[q]

.. how about an option for opening as many windows as you want, not as separate score documents, but as independent views of a single score? Imagine viewing linear and page views simultaneously. This would allow the user to monitor remote areas of the score, and copy/paste between them, without the need to scroll or change pages.

q

If we get view windows any time soon, it might be wise to include some safeguards when closing them.

When I close a non-dirty score, the window just disappears, meaning that nothing has changed since the file was opened, or the file has been saved since the last edit.

Now imagine closing a view window, thinking it was the only open score view. When it goes away silently, one could easily conclude that the score is saved (no longer dirty.) The result could be an open score that has not been saved, and whose window is out of site. In the event of a power outage, unsaved edits would be lost; when shutting down hastily — thinking that all work was previously saved — the user might choose "don't save."

Presently multiple instances open complete separately forks in one's workflow. Only the work in the last saved score gets saved. Very dangerous. Those instances should only be views only on the same file and the same workflow.

q