Home » Modeling » EMF » Is EMF suited for what I am trying to accomplish?
| Is EMF suited for what I am trying to accomplish? [message #1107060] |
Wed, 11 September 2013 23:16  |
 Gary Worsham
Messages: 176
Registered: September 2013 |
Senior Member |
|
|
I have used Eclipse to write a CAD type system in Java/Swing.
It is a system that generates DSP assembler code as its output. The idea is that you have a block called, for example, "Low Pass Filter" and you can connect this to the system input and output blocks and it will generate the DSP code to make that function happen on a specific DSP platform.
I've gotten to the point where the system itself works pretty well and now I am turning myself to generating more of the building blocks themselves. This part is exceedingly tedious and so I am searching for a way to both simplify the coding task and create more consistent and repeatable code.
To add a new functional block, I copy an existing block (class) and then change the details. The attributes of a block include:
The name
How many inputs does it have (0, 1, 2)
How many control inputs does it have (0, 1, 2, 3)
How many outputs does it have (0, 1, 2, 3)
How many control outputs does it have (0, 1, 2)
Parameters of the CAD block that want to be adjustable via a popup dialog, e.g.:
Filter frequency
Filter resonance
Filter type
A unique "generateCode()" method that handles generating the actual DSP assembler code while making variable substitutions to handle logical connections to the inputs and outputs.
Then I also create a corresponding class for the popup dialog which includes Swing controls and scaling methods for all of those block parameters which were called out as being adjustable.
Finally, I make an entry in my main class to add the new block to the menu. Selecting a block from the menu inserts it into the model.
This is all so tedious that I have just about given up further work on the program. However if there were a way to abstract some or all of this, so I could simply describe the new block attributes and have some tool generate the code, that would be really quite awesome.
Based on my description, do you think EMF is suited for this?
Thanks!
|
|
| |
| Re: Is EMF suited for what I am trying to accomplish? [message #1107419 is a reply to message #1107225] |
Thu, 12 September 2013 11:17  |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 12-09-13 07:35, Miles Parker wrote:
> Gary Worsham wrote on Wed, 11 September 2013 19:16
>> I have used Eclipse to write a CAD type system in Java/Swing.
>>
>> This is all so tedious that I have just about given up further work on
>> the program. However if there were a way to abstract some or all of
>> this, so I could simply describe the new block attributes and have
>> some tool generate the code, that would be really quite awesome.
>>
>> Based on my description, do you think EMF is suited for this?
>
>
> Hi Gary,
>
> Short answer is yes! Slightly longer answer is that the best combo for
> you would be to build a "DSP" DSL in Xtext and then use Xtend to
> generate the code you need. Or you could go directly from the Xcore
> model to generated code with Xtend and use the generated EMF editor to
> actually define your domain DSP model.. Or you could do some combination
> of both.
Or you could build upon the GMF example project called logic. (File ->
New -> Example -> Logic) in the Eclipse Modeling editing, which is a
graphical editor for logic diagrams. The output is a semantic and
notational EMF model, which you can transform to your code at will with
Xtend or other transformation engines for EMF. I woudn't even consider
building such an application without EMF :-)
>
> hth,
>
> Miles
|
|
| | | | |
| Re: Is EMF suited for what I am trying to accomplish? [message #1109499 is a reply to message #1109359] |
Sun, 15 September 2013 14:13 |
Gary Worsham
Messages: 176
Registered: September 2013 |
Senior Member |
|
|
Christophe Bouhier wrote on Sun, 15 September 2013 05:05On 14-09-13
If your model code is reasonably isolated, you could annotate it. EMF
can then process it. See the EMF tutorial for how this works.
Here's a screen shot of my app currently in action:
(I would have provided it but I can't link off eclipse.org until I have more than 5 messages posted)... sigh...
The primary "model" which this represents is a linked list of functional blocks represented by the colored rectangles. I have no desire or acknowledged need to recode this model at this time. What I am really trying to accomplish is an easier way to develop the classes for the blocks themselves.
Odd as it might seem, the starting point for each of these blocks/classes is a functional DSP algorithm targeting a very specific chip. The chip has resources (32 general purpose registers, 32k audio sample RAM, 3 control inputs, stereo input and output ports) that are shared between these blocks.
A functional block class replaces a standalone algorithm's fixed assignment of registers and delay memory by allocation calls, so that we use them up in the order that the blocks sort out in the model.
My vision is this:
1) (by hand) Start with a generic DSP algorithm (DSP assembler) that knows nothing about this environment and was written for the native assembler.
2) (by hand) Replace register and memory assignments with keywords as needed to reference my allocation routines.
3) Use the tool to create a new block definition and specify the block name and type (color) and number/type of inputs and outputs (although this can also be determined by scanning the code after step 2). Now the block class would be created and be inserted into one of the menus of the application (I guess which menu it should be in would also be part of its definition).
3.5) Add definitions for user-supplied data and how this maps to variables within the algorithm. For example, if you start by saying "I want a low pass filter at 350 Hz with a 6 dB peak)" this has to go through some mathematical contortions (which are handled by Java code) to create the coefficients that show up in the DSP code.
4) Pull in the reference tweaked DSP ASM code.
5) Press "Run" and the "stitching"/transformation between the supplied information and how I would normally code it by hand would be done. My application would pop up with the new functionality.
6) The generated classes (whether in model or generated Java code/class form) could be exported and shared between users of the program.
I am describing this in detail because I have gone through the xtext tutorial and while it worked and I said "wow", I didn't immediately click on how it related to the problem I was trying to solve. I will keep looking at it from different angles.
Thanks!
GW
[Updated on: Sun, 15 September 2013 14:16] Report message to a moderator |
|
|
| Re: Is EMF suited for what I am trying to accomplish? [message #1109500 is a reply to message #1109499] |
Sun, 15 September 2013 14:15 |
Gary Worsham
Messages: 176
Registered: September 2013 |
Senior Member |
|
|
as a further enhancement, once all of that is working, would be a way to specify the user adjustable parameters and how those map to Swing UI elements, e.g. is it a slider control, what's the range, radio buttons, spin control, etc.
[later that day...]
OK, I found the tutorial on generating an EMF model from annotated Java. I will go through this.
My code does not currently use any defined Interfaces, though this is probably just sloppy programming on my part. Each actual block you see is extended from a base class "SpinCADBlock". This class is very basic and just has place holders for most things which the actual blocks need to do. Seems like a good spot for an Interface.
Currently I use some intermediate classes which only currently override what COLOR the block will be. At one point, I thought "all modulation blocks will have a certain number of control inputs", however as time went on I had to back off on that. It seems I could eliminate one level of intermediate classes by supplying a definition of "block type" which would indicate what color it was and what menu it would be found in.
Thanks for the hint Christophe... more later...
[Updated on: Sun, 15 September 2013 14:38] Report message to a moderator |
|
| | |
| Re: Is EMF suited for what I am trying to accomplish? [message #1109954 is a reply to message #1109499] |
Mon, 16 September 2013 06:53 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi Gary,
I am not sure what to tell you, you seem to know exactly what you want.
All the domain specific terms you describe are really for entities,
attributes, relationships and operations. This is all what modeling is
about, you need to translate your domain terms and concepts in the
various models and shapes which would exist in the lifecycle of your
process. You have various EMF tools at your disposal which can help you
create, infer, transform, design, persist and type(xtext,xcore) your
model. You can go back and forth with these tooling. I find using EMF is
really about picking the right toolings and runtimes for the tasks at hand.
Some examples.
EMF Tooling:
Brain => (xcore, ecore, code, xsd) Meta model
EMF(.edit/.editor):
Eclipse/JFace/SWT UI + Metamodel = > Model instance
GMF Tooling:
ecore Meta Model => Notation (Graphical Metal Model)
GMF/Grafiti:
Graphical => Model instance, Notation model instance
Xtext Tooling:
Brain => (antlr like text) ecore Meta model
Xtext:
text => Model instance
Xtend:
Model Instance + Meta model => text(XML, HTML, whateverML) or debuggable
java code. (This is powerfull for code generation which you seem to need).
CDO, EMFStore, Teneo, File
Model Instance + Meta model => persist in i.e. RDBMS.
etc (Acceleo, .....)
Now as you start of with an existing application, I would in your case
determine for which steps etc.., which EMF technology would be suitable.
Hope this helps.
Cheers Christophe
On 15-09-13 16:13, Gary Worsham wrote:
> Christophe Bouhier wrote on Sun, 15 September 2013 05:05
>> On 14-09-13 If your model code is reasonably isolated, you could
>> annotate it. EMF can then process it. See the EMF tutorial for how
>> this works.
>
>
> Here's a screen shot of my app currently in action:
>
> {I would have provided it but I can't link off eclipse.org until I have
> more than 5 messages posted)... sigh...
>
> The primary "model" which this represents is a linked list of functional
> blocks represented by the colored rectangles. I have no desire or
> acknowledged need to recode this model at this time. What I am really
> trying to accomplish is an easier way to develop the classes for the
> blocks themselves.
>
> Odd as it might seem, the starting point for each of these
> blocks/classes is a functional DSP algorithm targeting a very specific
> chip. The chip has resources (32 general purpose registers, 32k audio
> sample RAM, 3 control inputs, stereo input and output ports) that are
> shared between these blocks.
>
> A functional block class replaces a standalone algorithm's fixed
> assignment of registers and delay memory by allocation calls, so that we
> use them up in the order that the blocks sort out in the model.
>
> My vision is this:
>
> 1) (by hand) Start with a generic DSP algorithm (DSP assembler) that
> knows nothing about this environment and was written for the native
> assembler.
>
> 2) (by hand) Replace register and memory assignments with keywords as
> needed to reference my allocation routines.
>
> 3) Use the tool to create a new block definition and specify the block
> name and type (color) and number/type of inputs and outputs (although
> this can also be determined by scanning the code after step 2). Now the
> block class would be created and be inserted into one of the menus of
> the application (I guess which menu it should be in would also be part
> of its definition).
>
> 3.5) Add definitions for user-supplied data and how this maps to
> variables within the algorithm. For example, if you start by saying "I
> want a low pass filter at 350 Hz with a 6 dB peak)" this has to go
> through some mathematical contortions (which are handled by Java code)
> to create the coefficients that show up in the DSP code.
>
> 4) Pull in the reference tweaked DSP ASM code.
>
> 5) Press "Run" and the "stitching"/transformation between the supplied
> information and how I would normally code it by hand would be done. My
> application would pop up with the new functionality.
>
> 6) The generated classes (whether in model or generated Java code/class
> form) could be exported and shared between users of the program.
>
> I am describing this in detail because I have gone through the xtext
> tutorial and while it worked and I said "wow", I didn't immediately
> click on how it related to the problem I was trying to solve. I will
> keep looking at it from different angles.
>
> Thanks!
>
> GW
>
|
|
|
| Re: Is EMF suited for what I am trying to accomplish? [message #1110184 is a reply to message #1107060] |
Mon, 16 September 2013 13:55 |
Gary Worsham
Messages: 176
Registered: September 2013 |
Senior Member |
|
|
Hi Christophe,
Thanks for the info and study recommendations. I'll just describe a thought that came to my mind.
In my existing application, all actual block classes are extended from the SpinCADBlock class. The original block has no DSP code reference and no special parameters which describe the block's behavior. When I make a derived class, I can add overridden methods easily and add whatever extra parameters are needed for that block.
These extra parameters are either double, integer, or boolean. There can be anywhere from zero to perhaps 15 or 20 parameters in a block.
Now when I'm trying to move this concept over to a "model" way of thinking, I am getting the impression that I either have to:
1) Describe the model as the superset of all possible parameters and just fill in the ones per new model instance that apply (although this hardly seems believable), or...
2) Change the approach from using specific data types in the extended class to using a reference, perhaps to a List, of a varying number and type of parameters, along with a corresponding list of methods to do various things with those parameters.
I learned Java at the beginning of the year for the express purpose of doing this project, and my leap into EMF serves the same end. I am not trying to acquire general skills that will aid my programming career; in real life I do manage a group of programmers and learning these concepts is certainly helpful for cutting through the occasional technical overload.
Merci,
GW
[Updated on: Mon, 16 September 2013 13:56] Report message to a moderator |
|
| |
| Re: Is EMF suited for what I am trying to accomplish? [message #1110485 is a reply to message #1110267] |
Tue, 17 September 2013 00:13 |
Gary Worsham
Messages: 176
Registered: September 2013 |
Senior Member |
|
|
Hmmm, I am starting to get the feeling that my current implementation needs to be whipped into shape a bit, models or no models, before it can be as flexible as I'd like it to be.
For example, I do not currently have a class defined as a "BlockParameter". Within my specific blocks I simply have a bunch of attributes, however many are needed, and setters/getters that link those with the Swing UI elements which are part of a different specific "xxxControlPanel" class that handles the manipulations of those attributes.
So, I think I need to start by abstracting those things off to a "BlockParamter" class that would include:
type,
range of acceptable values,
type of Swing UI control,
JPanel where these controls would be aggregated,....
|
|
|
| Re: Is EMF suited for what I am trying to accomplish? [message #1110726 is a reply to message #1110485] |
Tue, 17 September 2013 08:48 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Gary
It seems that a very large amount of what you want to port to EMF is
already provided in generic form by a variety of Eclipse projects.
So
- you do nothing
- you port your existing code to EMF and forever compete with similar
evolving Eclipse technologies
- you rewrite to exploit many Eclipse technologies
Only 'do nothing' is 'easy'. The other two are both going to be very
time consuming as you learn more about what you want to do.
Throwing away your own code is very painful. Learning new technologies
is painful. Competing with Eclipse projects can be counterproductive.
Don't start something you haven't got time and resources to complete.
Don't do anything large until you've experimented.
Regards
Ed Willink
On 17/09/2013 01:13, Gary Worsham wrote:
> Hmmm, I am starting to get the feeling that my current implementation
> needs to be whipped into shape a bit, models or no models, before it
> can be as flexible as I'd like it to be.
>
> For example, I do not currently have a class defined as a
> "BlockParameter". Within my specific blocks I simply have a bunch of
> attributes, however many are needed, and setters/getters that link
> those with the Swing UI elements which are part of a different
> specific "xxxControlPanel" class that handles the manipulations of
> those attributes.
>
> So, I think I need to start by abstracting those things off to a
> "BlockParamter" class that would include:
>
> type,
> range of acceptable values,
> type of Swing UI control,
> JPanel where these controls would be aggregated,....
>
>
|
|
|
| Re: Is EMF suited for what I am trying to accomplish? [message #1110899 is a reply to message #1110726] |
Tue, 17 September 2013 13:33 |
Gary Worsham
Messages: 176
Registered: September 2013 |
Senior Member |
|
|
Thanks Ed, I appreciate your perspective. Another of my challenges is trying to select the best approach without having to become an expert in all of them first!
The reason I'm divulging my inner thoughts is that in spite of the opportunity for public humiliation it does actually help focus my thoughts. I also reviewed (again) last night a comparison of ECore to Annotated Java for EMF model generation.
http://www.vogella.com/articles/EclipseEMF/article.html
What I got from doing the model by annotating my existing Java code was a model that couldn't really go anywhere because the underlying Java structure wasn't amenable to it. What I got from reading the ECore tutorial was an idea that by using the ECore tool I could create a structure for my class without having to guess what all the E-possibilities were. So that is what my next step is going to be.
Just to be clear, my goal here is to generate a means for other people, who are not necessarily Java savvy, to add functional DSP blocks to this tool. They will start with a reference standalone DSP code algorithm, with certain constraints/guidelines, and then build an ECore model that hooks into that, to allow creation of a new block within the program and a control panel to adjust certain parameters of the block.
Next step, experiment with ECore.
[Updated on: Tue, 17 September 2013 13:38] Report message to a moderator |
|
|
Goto Forum:
Current Time: Fri Apr 26 19:46:56 GMT 2024
Powered by FUDForum. Page generated in 0.03782 seconds |
] 
Search
Help
Register
Login
Home
