publishing an intermediate release 3.1.0?

Understood. Thanks, I used fork without knowing the difference.

As WheresWaldo said I will place a pull request to PBs repo so all changes can be easily included in the main deviation repository.
For now forking my repo and placing pull requests to mine is the easiest way to get your changes integrated in the coming 3.1 version.

Yes, could be a way, and more and more I think it will be the best way because we easily get all occurrences of a channel in the config (and it is a simple text parsing instead of knowing what happens in the model / mixer structure and where values are stored which can refer to a channel...). We can also do some checking and skip the remapping if the prerequisites do not fit.
But I don't know how much space is required for that and if it will be implementable for all tx models.

Published beta-02 with only changes to th language files.

Sorry - leftover from analyzing the language files (versions from commit 1860).
I did not realize that they are included in the fs-zips.
EDIT: I have uploaded the correct zip files.

I have two quick questions:

1. Are we going to use this thread for open discussions of bugs/fixes/code changes?
2. If Deviation uses the files in /filesystem/common/layout/ during the build process is there a need to duplicate that same structure with the same files in the /filesystem/devo10/layout/ sub-directory?

I ask question #2 because clear.ini does not have a blank section for the 128x64 screen type, and for consistency it should be there even if deviation defaults to a blank model configuration screen when you load clear.ini. I modified the files and tested this with both the emulator and my devo10 and then made a pull request. The same situation applies to default.ini, why is there a need for one in common and another in the devo10 sub-directories (the devo8/12 system doesn't seem to need it and it builds correctly)?

Thanks in advance.

Quick answer for (1): we can discuss here but I think better will be a ne thread or even an issue in my repo to have it concentrated at one place...

(2): I did not investigate those new design templates yet. I hope I can have a look at the weekend. I saw your pull request and have to understand what you want to be pulled so I have to learn about...

rbe2012 wrote: Quick answer for (1): we can discuss here but I think better will be a ne thread or even an issue in my repo to have it concentrated at one place...

(2): I did not investigate those new design templates yet. I hope I can have a look at the weekend. I saw your pull request and have to understand what you want to be pulled so I have to learn about...

I think I did the pull request correctly, I made two small changes to clear.ini in common/layout and devo10/layout they were simply the addition of line 4 which is "[gui-128x64]" then committed both file changes to my repo, then made a pull request to yours to pull those two files. Was that not the correct way to make a pull request?

WheresWaldo wrote: I think I did the pull request correctly, I made two small changes to clear.ini in common/layout and devo10/layout they were simply the addition of line 4 which is "[gui-128x64]" then committed both file changes to my repo, then made a pull request to yours to pull those two files. Was that not the correct way to make a pull request?

Yes, you did it correct. But I have to understand what your changes mean and since I don't know anything about the gui templates I have to read and learn...
It has nothing to do with the work you have done. I regret having been misunderstandable...

I got it! It took some time to find all the relevant places in the code...

Vlad, you don't see any difference because if a section does not exist it can not contain any parameters - this leads to an empty page. But for clarifying (and because it does not cost anything, because every file is at least 4kB of size) I added it.
WheresWaldo: I have declined your pull request because I did not wand to insert a new file (the one in Devo10 folder) and made the change manually. Don't get confused.

Minor issue with the length of the version string (because it contains quotes which I didn't count). Fixed.

RBE, you needn't worry about hurting my feelings if you decline anything I offer, I do not take offense.

Why not eliminate the filesystem\devo10\layout\ directory altogether with fix 4b971f1?

As I have mentioned before, I am not a programmer but when I see two source files with the same info I tend to want to make sure both are edited the same way, that filesystem\devo10\layout\ directory seems useless and it along with the files in it should be removed.

Note: I probably should have added the above statement to the commit on bitbucket, I am doing that now.

Often what looks like duplicate files and folders is for the compile process. The target variables need to be there or you might not be able to compile for that particular target.

That's great news guys I already push some changes to the main repo like two months ago ... and no body replied so I got demotivated and thought that the project was dead.

I will then fork your rbe repo and I will push there the changes.

Thanks

vlad_vy wrote: RBE, can you say what I need to do to get version info? I simply download sorce files archive and build firmware, but version always = devo8-Unknown.

Vlad

I think if you use Mercurial to clone the remote repo to your local drive, then you will get the hg (mercurial/bitbucket)versions included when you build the local repo. That is how I do it and I get ZRBE's 3.1-beta versions.

Vlad,
RandMental guesses right. The version is determined from the "hg log" command - you wll get a wrong version number (or "unknown") if you don't have the correct mercurial repository information. You can look at utils/get_version.pl.