vasile

Hi, please check second line of this. Kind regards.

Hi cisco150,
Well, the effort is/was spread between various contributors (in temporal order of first contribution):
Otto - initial break in the camera (through information gleaned from the NX500 service manual, which allowed access to a root shell); also various utilities that are enhancing the photo side of the camera as well as providing the user interface you can see used by various mod packs, and the bluetooth hook; low bitrate 2.5K mod for NX500. Myself: all my work to date was basically about video: access to DEV menu to (among others) disable video recording limits, high bitrates for all video modes for NX1 and NX500 and high bitrate for NX500 / 2.5K. I am also looking into other more difficult aspects of the camera operation but I won't comment about it because nothing came out yet. Kino Seed (and maybe others) - packaging and fine tuning the results of 1. and 2. above. If you would like to recognize the above work there's no one place for everything: Otto suggests you contribute to a charity as a recognition of his efforts. I am looking to get some more NX lenses (so far I am about 1/3 :-( of the way to my first wish (take a look here), and Kino Seed did not mention anything.
In addition, you might pledge here to help make a camera available to me to (a) stop using my own camera for my investigations - two months of intensive research use resulted in a loose power button that needs replacement and (b) to enable some dangerous experiments for which I do not dare risk my own camera but which might benefit the user base - an example would be a permanent hook that does not depend on bluetooth and would be instantly available upon power on.
Hope this helps
regards

Hi cisco150,
Well, the effort is/was spread between various contributors (in temporal order of first contribution):
Otto - initial break in the camera (through information gleaned from the NX500 service manual, which allowed access to a root shell); also various utilities that are enhancing the photo side of the camera as well as providing the user interface you can see used by various mod packs, and the bluetooth hook; low bitrate 2.5K mod for NX500. Myself: all my work to date was basically about video: access to DEV menu to (among others) disable video recording limits, high bitrates for all video modes for NX1 and NX500 and high bitrate for NX500 / 2.5K. I am also looking into other more difficult aspects of the camera operation but I won't comment about it because nothing came out yet. Kino Seed (and maybe others) - packaging and fine tuning the results of 1. and 2. above. If you would like to recognize the above work there's no one place for everything: Otto suggests you contribute to a charity as a recognition of his efforts. I am looking to get some more NX lenses (so far I am about 1/3 :-( of the way to my first wish (take a look here), and Kino Seed did not mention anything.
In addition, you might pledge here to help make a camera available to me to (a) stop using my own camera for my investigations - two months of intensive research use resulted in a loose power button that needs replacement and (b) to enable some dangerous experiments for which I do not dare risk my own camera but which might benefit the user base - an example would be a permanent hook that does not depend on bluetooth and would be instantly available upon power on.
Hope this helps
regards

Hi cisco150,
Well, the effort is/was spread between various contributors (in temporal order of first contribution):
Otto - initial break in the camera (through information gleaned from the NX500 service manual, which allowed access to a root shell); also various utilities that are enhancing the photo side of the camera as well as providing the user interface you can see used by various mod packs, and the bluetooth hook; low bitrate 2.5K mod for NX500. Myself: all my work to date was basically about video: access to DEV menu to (among others) disable video recording limits, high bitrates for all video modes for NX1 and NX500 and high bitrate for NX500 / 2.5K. I am also looking into other more difficult aspects of the camera operation but I won't comment about it because nothing came out yet. Kino Seed (and maybe others) - packaging and fine tuning the results of 1. and 2. above. If you would like to recognize the above work there's no one place for everything: Otto suggests you contribute to a charity as a recognition of his efforts. I am looking to get some more NX lenses (so far I am about 1/3 :-( of the way to my first wish (take a look here), and Kino Seed did not mention anything.
In addition, you might pledge here to help make a camera available to me to (a) stop using my own camera for my investigations - two months of intensive research use resulted in a loose power button that needs replacement and (b) to enable some dangerous experiments for which I do not dare risk my own camera but which might benefit the user base - an example would be a permanent hook that does not depend on bluetooth and would be instantly available upon power on.
Hope this helps
regards

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

Hi cisco150,
Well, the effort is/was spread between various contributors (in temporal order of first contribution):
Otto - initial break in the camera (through information gleaned from the NX500 service manual, which allowed access to a root shell); also various utilities that are enhancing the photo side of the camera as well as providing the user interface you can see used by various mod packs, and the bluetooth hook; low bitrate 2.5K mod for NX500. Myself: all my work to date was basically about video: access to DEV menu to (among others) disable video recording limits, high bitrates for all video modes for NX1 and NX500 and high bitrate for NX500 / 2.5K. I am also looking into other more difficult aspects of the camera operation but I won't comment about it because nothing came out yet. Kino Seed (and maybe others) - packaging and fine tuning the results of 1. and 2. above. If you would like to recognize the above work there's no one place for everything: Otto suggests you contribute to a charity as a recognition of his efforts. I am looking to get some more NX lenses (so far I am about 1/3 :-( of the way to my first wish (take a look here), and Kino Seed did not mention anything.
In addition, you might pledge here to help make a camera available to me to (a) stop using my own camera for my investigations - two months of intensive research use resulted in a loose power button that needs replacement and (b) to enable some dangerous experiments for which I do not dare risk my own camera but which might benefit the user base - an example would be a permanent hook that does not depend on bluetooth and would be instantly available upon power on.
Hope this helps
regards

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

http://***URL removed***/forums/post/57685081

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

He he, I don't think it's a bug, it's a feature :-)
Otto could not check whether the LCD is on or off in his programs without access to a NX1 to find out how - NX500 has no VF - :-) so he did his best under the circumstances...
Just make sure you do any stuff which pops messages on the screen, while the screen is on and not while using the viewfinder.

He he, I don't think it's a bug, it's a feature :-)
Otto could not check whether the LCD is on or off in his programs without access to a NX1 to find out how - NX500 has no VF - :-) so he did his best under the circumstances...
Just make sure you do any stuff which pops messages on the screen, while the screen is on and not while using the viewfinder.

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

(1) and (2): Some explanations.
Scripts are stored on the SD card. SD cards are optimized for sustained writes and generally slower than internal emmc flash, especially for mixed read/writes. When you start to mix script reads and video writes you are confusing the sdcard (internal) flash memory controller and since the card is optimized for large writes it will behave badly for short reads like those of scripts. Especially when these are comparatively rare in between long sustained writes. The ARM core running Tizen and the user interface is single threaded and not very fast (the fast ones are running the non-Tizen T-Kernel operating the camera hardware). You WILL see slowness because the UI has to wait for the keyscan to finish which in turn waits for the scripts to finish which in turn get read from a (comparatively) slow card the SD before it (the UI) can continue with whatever it was doing. the scripts heavily use the Linux shell, launching it every single time a script is launched (and remember for us scripts are launching other scripts - nested scripts). Bottom line, there are several things someone will need to do before you will get better performance:
RUN, don't walk, from storing any script/mod/hack on SD card. This is the single greatest reason for slowness, and to make things worse, it is highly dependent on card model (and more expensive cards will not necessarily make things better because it may happen that high end cards will work less well for small reads than cheaper "non-optimized for writes" cards. Otto is doing something about this but AFAIK it is still experimental although not rocket science. But you will also have to overcome your fear of storing mods internally. After all, once you did the BT mod, you basically did 95% of what is required anyway and successfully passed the "dangerous" phase of changing camera rootfs. I do think that we need to improve that mod to enable mod bypass during boot just in case something goes wrong with any of the internal mods, and that we need to have a "mod witness" permanently on the screen to show that mods are enabled, but this is minor. Eliminate multiple scripts from "production" mods. Scripts are fantastic for getting functionality in your hands and to allow fast test turnaround and mod interface evolution but ultimately there needs to be a consolidated mod that sits in ONE binary. This is, by the way, I think, one of the reasons for the fat di-camera-app that runs the entire camera UI. Script support needs to stay (both card and internal) but over time, all mods should aspire to be part of a main mod binary. Ideally, a mod should go through multiple stages: SD card based while it is evaluated and goes through fast changes and updates and while we are NOT CERTAIN that it will not damage the camera internal when determined as safe for camera and changes are not so frequent once stable and generally accepted, optimize and integrate as binary (non-shell script) in a main executable mod for fastest speed. There you go.
Also, from what I can see in the firmware, it seems that the data flow in the camera goes: Sensor => DRIME (that is operated by T-Kernel) => Tizen kernel => write on card. The reason Tizen and not T-Kernel writes on card is that you cannot have multiple operating systems write on the card at the same time. This means that if we bloat memory use on Tizen, its capacity to maintain sustained writes is lowered compared to what it might achieve with more free RAM. In turn, this means: avoid shell scripts or heavy programs (like my gdb bitrate mod version).
This, IMO, is also the reason the "poker" method allows faster performance than the "gdb" method. It is also the reason I am working towards an even better method than "poker" which will consolidate the "memory change" mods in one binary without the need to stop the di-camera-app multiple times (which is very time consuming for the CPU).
Finally: Would anyone mind starting something like a gofundme campaign for a NX500. Mine needs a replacement power button (I kind of abused mine I guess) and I am reluctant to keep working on it after I get it repaired.
It is too bad because with time, based on what I see in the camera, and if there was a developer community built around it, the hardware could achieve wonders. And to be clear, Otto, Kino Seed, Chant, and me do not "community" make IMO, like for example Magic Lantern. If you guys want anything close to ML you will need to do a lot more about spreading the word and competing for developers time/recruiting new ones.
Regards
Vasile

http://***URL removed***/forums/post/57685081

http://***URL removed***/forums/post/57685081

http://***URL removed***/forums/post/57685081

hope you find it useful ;-)

Well I cannot stop anyone from asking, but I will keep with my "no promise" vow.
And "keep that in mind" does not constitute a promise BTW, in case you were wondering :-)