Re: [Bluemusic-users] blueX7 - Where to go from here?

[Brian W. <bri...@ho...>]

Personally I do not have any important existing projects that use blueX7, so backwards compatibility is not an issue for me. What you describe sounds very interesting and useful. I never owned a DX7 and found the blueX7 interface "challenging" to work with. The prospect of a more intuitive full matrix design which still retains the ability to load DX7 patches sounds great to me! Some thoughts :
- It would be nice to have access to the instrument source code so that we could modify it if desired, and study it for learning purposes.
- I am currently working on a similar full matrix 6-osc PM synth that has the option to do ring modulation instead of phase modulation. My idea is to treat amount of ring modulation (mixing with unmodulated signal) the same as modulation index for PM. I realize that this is a departure from the DX7 PM-only design and adds complexity, but please consider it.
BW

> Date: Sat, 22 May 2010 12:31:25 -0400
> From: ste...@gm...
> To: blu...@li...
> Subject: [Bluemusic-users] blueX7 - Where to go from here?
> 
> Hi All,
> 
> I was emailed off list about blueX7 and how it's pretty much a
> unsatisfying experience, to which I agreed.  I wrote it many years ago
> when I was not as knowledgeable about both Csound and Java
> programming, and I think it can be much better. The issues I see are:
> 
> 1. It uses the Pinkston DX7 emulation instruments - there seems to be
> an inefficiency in how these instruments process, and they do not
> support PEG (and perhaps other features).  I think the solution is to
> work from a clean FM instrument design.
> 
> 2. It's very DX7 oriented - I am thinking a new blueX7 should be
> created that approaches FM differently but at the same time is
> compatible with DX7 patches.  Much like Native Instruments FM8 takes a
> different UI approach to FM, but supports DX7 patches (though, I would
> not want to copy FM8, if but for legal reasons alone).
> 
> 3. It was never updated for automation.
> 
> 4. It is buggy.
> 
> 5. Users may have projects that use the existing blueX7 (backwards
> compatibilty).  One option here is to remove blueX7 from the add
> instrument menu, but keep it there in the background so that projects
> that use it can still load it, but newer projects won't be able to add
> it unless they copy/paste it from an older project.  The other option
> is to make the new FM/PM instrument still be called blueX7 and have it
> auto-migrate from older projects to the new blueX7 (this would be fine
> too, may be the better way forward).  The new blueX7 would have to
> have the output be audio-equivalent when upgrading from older blueX7
> instances, which can be done.
> 
> 
> I think the first step is to make sure that the new blueX7 supports
> the full set of features for DX7 patches, plus do a review to find any
> bugs in the UI and fix them.  Also, I think we should also very much
> redo the Csound instrument code.  Csound coding practices have changed
> a good bit since the Pinkston emulations were done, and I've modified
> my own Csound instrument design approach due to the recent work with
> MIDI input.
> 
> I know others have mentioned issues with blueX7 in the past; if you
> could reply to this email with any issues you remember and any
> features you imagine or UI changes to suggest, I would love to hear
> any feedback.
> 
> Thanks!
> steven
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Bluemusic-users mailing list
> Blu...@li...
> https://lists.sourceforge.net/lists/listinfo/bluemusic-users
 		 	   		  
_________________________________________________________________
Win $10,000 from Hotmail! Enter Here.
http://go.microsoft.com/?linkid=9729708