. always long-winded answers to everything containing vast amounts of information.i can implement that behaviour fairly easy,i just implemented it this way since someone requested it and it wasnt capable of that, so i wanted to do it in order to make sure it worked. we can do just about anything with overlay (always-on-top) and background (always behind) layers now. the dropbox isnt specifc to what can be held inside the "drop" control. in this case it is a region with a 3d effect, containing 16 textboxes with the letters, but it can be _anything_. it is possible to have the dropbox control open and close only when it is clicked, making it like a window. i can also make it possible to drag it around, or make the down-arrow the only possible way to open/close the drop meaning it will have pretty full window behaviour.
so remember absolutely anything can go in that drop window, anything can also go in the dropbox control. currently i'm actually using a region with 3d effect, a textbox and an imagebox (bitmap) for the arrow. the arrow is automatically drawn so it isnt nessicary to store a bitmap for it. anything that can be drawn by xhip anywhere on the gui can be drawn into an offscreen bitmap. anything that can be placed anywhere in the main gui window can be placed in any sub-window, which includes any type of control. the base object called a "frame" is abstract and can contain other "frame" objects. this means any object can contain any other object. i've recently added a background (drawn before everything else) and overlay (drawn after) list of objects to the base frame object. events like the mouse and keyboard are not sent to the background and overlay, so they are only intended to display graphics.
if you prefer your gui to have that behaviour, that is the behaviour it will have of course. it might be a good idea for us to use the config/ini to have the other behaviour selected by the user though since it was requested.
- i dont know yet, if i knew i'd implement themAre Waveshaper Symmetry and Keytracking going to be implemented?
just leave them off the gui. it doesnt matter if the gui you do lacks full functionality, that is the good thing about the way xhip is designed. you can ignore the 2nd osc for example and xhip will still work perfectly. in the gui code i would just set to always disable the 2nd osc. the gui code controls loading patches, banks and other files, so the patch parameters can be filtered by the gui. the gui is a "control" layer for the synth remember, so the synth is owned by the gui. the gui has absolute control - it can do anything you want it to.
i have not decided yet. i think it will be better to remove the inital phase options completely once the event-routing system is working since it will be possible to use it for those purposes instead - with much greater flexibility.Will initial phase for oscillators/LFOs be available as parameters?
samples are stored in a sample-bank, not by the oscillators or by the patches. so it will be per-sample. it will be easy of course to create duplicate samples when editing with maybe a "duplicate pcm" button or something, so that sample can be edited while maintaining the original. there are problems with the current pcm system, samples should be selected by some id code, not by their position in the sample-bank. i've considered using filenames and other things but i have not decided on the best solution yet.Will sample editing be per oscillator or per sample?
they're in the mixer because they adjust the mixer amplitdes, it makes most sense this way. the oscillators are unchanged. yes, the invert controls work with every signal because they simply change the amplitude of the mixer to negative range. so they switch osca * amplitudea into osca * (-amplitudea). you should notice the parameter-filter actually is applied on this, so when you use the switch you should hear the signal quickly fade out and then fade back in inverted.Is there a reason why the oscillators' Invert controls are in the mixer section? Would it be better to put them attached to each oscillator? And do they work with PCM waves?
no, they do not at this time. this is a kludge and it should really be changed. i was thinking maybe we could use a oscillator panel which changes it's contents based upon which waveform is selected. for now it doesnt matter, we can always make changes as changes are made to xhip. our only major concern with the guis will be with beta releases which occur infrequently, so it isnt something we need to worry about. the default auto-generated gui needs changes to be made sometimes too like when the parameters no longer fit into the panels i allocated for them. i've changed it several times over it's lifetime so far. i just did not want to develop a complex discrete gui since i would need to make more changes when testing - when testing i prefer to immediately have the gui update itself so i can concentrate on the code i'm working on instead of worrying about the gui.Do negative values in Pulse Width have a meaning when the waveform is ramp or triangle?
it resets the envelope position to zero on a new note. this will of course make very loud clicks, but it is required if you want the envelope to be reproduced exactly the same way every time. i added several new options to allow new notes to reproduce perfectly every time for drum sounds and others as requested by.. well, i cant remember who requested it, was it brok? have a look back a few pages and you'll see it.What does Reset in Envelope Trigger do?
yes, in poly 1 mode the polyphonic options for glide apply instead of the monophonic options. every new note retriggers, and old notes are not remembered. only the newest note plays, and after another note is played it is the only one active. if you play C D E and release D, then release E, in monophonic mode you will hear C. in poly 1, all the notes will be shut off.Does Poly 1 mode make sense?
- not an exact quotexhip is always changing, etc
i know, this sucks. this is what i was refering to when i was talking about the dfficulties of taking on such a project. my advice is, do not stress yourself over issues which are not important. the current design is pretty stable, and we can of course discuss things when you have questions or issues. what you should do is try to implement the things you know are in xhip already, already used and well understood. leaving things out of the gui isnt a problem, if they're features like the waveshaper symetry nobody will notice since i have not implemented that yet anyway.
once we have a good gui working, we can always go back and make minor (or even major!) changes. i do not think adding or subtracting a control in some places will create major issues for your design. this is the constant engineering problem every software developer will face, the problem of how to make refactorization most easy, or to avoid it as much as possible. it isnt possible to completely avoid it, if it were, there would be so such thing as software bugs, only one version (windows 1.0) of every peice of software. this of course doesnt just apply to software.. imagine the horrors of a city-works engineer in a large city as entire districts of his/her city are reconstructed in new forms every year.
