I'm QUITE excited (but we have seen this before...)

[Phil.c]

Please excuse my ignorance but I understand your intention is to replace the cpu, if so, what would run the d8b, a pc maybe?

[arjepsen]

My aim is to have it running on my raspberry pi 3B+
It's a relatively cheap device, and it shooooould probably be powerful enough to do it, but I wont know for sure untill the bigger structure of the program is in place, including all the communication.
My initial tests are positive though.

But the code should be portable enough to run on any general linux distribution, whether you run it on a raspberry pi or a pc shouldn't matter.

Essentially the mixer is controlled by two dsp processors - one on the brain board, and one on the dsp board.
The cpu unit is handling the graphical user interface, and the communication to and from both boards.
Since the communication for each board is made up of a number of specific commands it can send and receive, the whole communication actually isn't all that complex in itself - hence my initial excitement

[Phil.c]

the whole communication actually isn't all that complex in itself - hence my initial excitement

No problem then....I'll sort it over the weekend

[doktor1360]

My aim is to have it running on my raspberry pi 3B+
It's a relatively cheap device, and it shooooould probably be powerful enough to do it, but I wont know for sure untill the bigger structure of the program is in place, including all the communication.
My initial tests are positive though.

But the code should be portable enough to run on any general linux distribution, whether you run it on a raspberry pi or a pc shouldn't matter.

Essentially the mixer is controlled by two dsp processors - one on the brain board, and one on the dsp board.
The cpu unit is handling the graphical user interface, and the communication to and from both boards.
Since the communication for each board is made up of a number of specific commands it can send and receive, the whole communication actually isn't all that complex in itself - hence my initial excitement

Hey Anders...

The code is gonna be 'portable' in a sense that it can be downloaded to compile on a specific architecture/platform to 'make' (no pun intended) an executable. For instance, you'd be compiling a binary for any Debian/Ubuntu based operating system... wherein I'd gladly at that point roll one up for any RedHat/Fedora/CentOS release for ya... that would essentially cover the vast majority of Linux platforms in use. Anyone with another 'flavor' could then grab the source from the curator (you) @ GitHub and have at it for their own platform...

All that being said, you're doing some wonderful work to date... quite honestly, you've gotten a helluva lot farther in the relatively short time you've invested in this endeavor than I would have estimated - I applaud your drive in reaching your goal(s)! I took a peek at the source (a good bit of it), and you definitely know what you're doing... the api class architecture is looking good, I particularly like the way it's stubbed out for future implementation. As an 'alert', as the project gets larger (the # of lines of code) I highly would recommend being very cognizant of using OOP methodology in your planning - it's very important for keeping things 'clean' and maintainable. The reason I mention this is, I'm a retired 'old dog' with 35+ yrs in hi-tech 'seat time', going all the way back to the early 80's (yeah, I just put a carbon date stamp on myself). When the count on the line of source increases, organization will be key... keep it class based, dynamic and event driven (respective of polymorphism, encapsulation & inheritance concepts). You'll save yourself time and headaches (and anyone else working on the project as well)...

But I digress... and pardon for the oration on the topic, I'm just payin' it forward to help in any way possible - it's not meant to be any "you should do this" sort of exchange whatsoever. I honestly hope that this aids in your decision making as you press forward... and of course, I have the confidence you will... just hit me up if need be at any point moving forward; at your discretion and in complete confidence...

Oh, and you knew this was coming too... so, ya know, here it is :
[Standard Mgmt Disclaimer] - "Your actual mileage may vary..."

Enjoy your weekend, Bud...

\m/

[csp]

Guys,

I wish that I could speak and understand the language that is spoken on what ever planet you two come from !!!!!

BUT, I do wish you all the best of luck with whatever project you are working on if it gives more life to the desk.

David

[arjepsen]

My aim is to have it running on my raspberry pi 3B+
It's a relatively cheap device, and it shooooould probably be powerful enough to do it, but I wont know for sure untill the bigger structure of the program is in place, including all the communication.
My initial tests are positive though.

But the code should be portable enough to run on any general linux distribution, whether you run it on a raspberry pi or a pc shouldn't matter.

Essentially the mixer is controlled by two dsp processors - one on the brain board, and one on the dsp board.
The cpu unit is handling the graphical user interface, and the communication to and from both boards.
Since the communication for each board is made up of a number of specific commands it can send and receive, the whole communication actually isn't all that complex in itself - hence my initial excitement

Hey Anders...

The code is gonna be 'portable' in a sense that it can be downloaded to compile on a specific architecture/platform to 'make' (no pun intended) an executable. For instance, you'd be compiling a binary for any Debian/Ubuntu based operating system... wherein I'd gladly at that point roll one up for any RedHat/Fedora/CentOS release for ya... that would essentially cover the vast majority of Linux platforms in use. Anyone with another 'flavor' could then grab the source from the curator (you) @ GitHub and have at it for their own platform...

All that being said, you're doing some wonderful work to date... quite honestly, you've gotten a helluva lot farther in the relatively short time you've invested in this endeavor than I would have estimated - I applaud your drive in reaching your goal(s)! I took a peek at the source (a good bit of it), and you definitely know what you're doing... the api class architecture is looking good, I particularly like the way it's stubbed out for future implementation. As an 'alert', as the project gets larger (the # of lines of code) I highly would recommend being very cognizant of using OOP methodology in your planning - it's very important for keeping things 'clean' and maintainable. The reason I mention this is, I'm a retired 'old dog' with 35+ yrs in hi-tech 'seat time', going all the way back to the early 80's (yeah, I just put a carbon date stamp on myself). When the count on the line of source increases, organization will be key... keep it class based, dynamic and event driven (respective of polymorphism, encapsulation & inheritance concepts). You'll save yourself time and headaches (and anyone else working on the project as well)...

But I digress... and pardon for the oration on the topic, I'm just payin' it forward to help in any way possible - it's not meant to be any "you should do this" sort of exchange whatsoever. I honestly hope that this aids in your decision making as you press forward... and of course, I have the confidence you will... just hit me up if need be at any point moving forward; at your discretion and in complete confidence...

Oh, and you knew this was coming too... so, ya know, here it is :
[Standard Mgmt Disclaimer] - "Your actual mileage may vary..."

Enjoy your weekend, Bud...

\m/

Thanks - I do try my best to keep it a bit of organized, but I am also learning as I go.
As I think I mentioned, I'm now finishing my internship with Pascal Audio, and will be writing my bachelor assignment in collaboration with them, so I don't know if I will be able to invest the same amount of hours during the next semester.
But it is something I enjoy doing, so we'll see.

Anyway, when you mention your experience, I do start to wonder if it is possible to divide the work. Let me know if you have an idea on how you could participate.
If you are good with diagrams and documenting program structure, you would be welcome to draw up some suggestions - right now I do have a general idea, but it's mostly in my head.
Generally, I am trying to keep the UI and the communication logic separated, and trying to ensure everything communicates through a general class (MixerManager), to avoid "spaghetti-code", where sort of intertwines...

BTW. there is a bit of information I do not have on hand.
During the boot process, the Brainboard queries the Tape Card slots.
I have OPT-8's and AIO-8's on hand.
I also have an Apogee clock card, so I have extracted the ID strings they send back on that query.
However, I don't have any "tdif" or other cards that might be available for the IO slots, so if anyone is bold enough to wanna have a go at querying theirs, let me know.

[arjepsen]

Just a little update:
https://youtu.be/yo22e5ALd5U

[csp]

Anders,

Don't fully understand it all but what you have achieved looks verty interesting.

David